Re: /proc/self/oom_adj is deprecated in newer Linux kernels

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