Re: /proc/self/oom_adj is deprecated in newer Linux kernels
От | Peter Eisentraut |
---|---|
Тема | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
Дата | |
Msg-id | 1316420754.14001.3.camel@fsopti579.F-Secure.com обсуждение исходный текст |
Ответ на | Re: /proc/self/oom_adj is deprecated in newer Linux kernels (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: /proc/self/oom_adj is deprecated in newer Linux kernels
|
Список | pgsql-hackers |
On sön, 2011-09-18 at 12:21 -0400, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > On fre, 2011-09-16 at 10:57 -0400, Tom Lane wrote: > >> So it looks like it behooves us to cater for oom_score_adj in the > >> future. The simplest, least risky change that I can think of is to > >> copy-and-paste the relevant #ifdef code block in fork_process.c. > >> If we do that, then it would be up to the packager whether to #define > >> LINUX_OOM_ADJ or LINUX_OOM_SCORE_ADJ or both depending on the behavior > >> he wants. > > > There are lots of reasons why that won't work: backports, forward ports, > > derivatives, custom kernels, distribution upgrades, virtual hosting. > > [ shrug... ] These are all hypothetical reasons. A packager who > foresaw needing that could just turn on both write attempts, or for that > matter patch the code to do whatever else he saw fit. In practice, > we've not had requests for anything significantly smarter than what is > there. > > But having said that, it wouldn't be very hard to arrange things so that > if you did have both symbols defined, the code would only attempt to > write oom_adj if it had failed to write oom_score_adj; which is about as > close as you're likely to get to a kernel version test for this. Why is this feature not a run-time configuration variable or at least a configure option? It's awfully well hidden now. I doubt a lot of people are using this even though they might wish to.
В списке pgsql-hackers по дате отправления: