Excerpts from Tom Lane's message of vie sep 16 13:37:46 -0300 2011:
> Greg Stark <stark@mit.edu> writes:
> > On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Does anyone want
> >> to argue for doing something more complicated, and if so what exactly?
>
> > Well there's no harm trying to write to oom_score_adj and if that
> > fails with EEXISTS trying to write to oom_adj.
>
> Well, (1) what value are you going to write (they need to be different
> for the two files), and (2) the main point of the exercise, at present,
> is to avoid kernel log messages. I'm not sure that trying to create
> random files under /proc isn't going to draw bleats in the kernel log.
I guess the question is what semantics the new code has. In the old
badness() world, child processes inherited the oom_adj value of its
parent. What the code in fork_process was used for was resetting the
value back to 0 (meaning "kernel is allowed to kill this process on
OOM"), so that you could set the oom_adj in the start script for
postmaster (to a value meaning "never kill this one"), and the backends
would see their values reset to zero.
The new oom_score_adj has a scale of -1000 to +1000, with zero being
neutral and -1000 being "never kill". So what we want to do here in
most cases, it seems, is set the value to zero whether it's oom_adj or
oom_score_adj -- assuming the new code is still causing children
processes to inherit the "adj" value from the parent.
Now the problem is that we have defined the LINUX_OOM_ADJ symbol as
meaning the value we're going to write. Maybe this wasn't the best
choice. I mean, it's very flexible, but it doesn't seem to offer any
benefit over a plain boolean choice.
Is your proposal to create a new LINUX_OOM_SCORE_ADJ cpp symbol with the
same semantics?
The most thorough documentation on this option seems to be this commit:
https://github.com/mirrors/linux-2.6/commit/a63d83f427fbce97a6cea0db2e64b0eb8435cd10#include/linux/oom.h
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
