Skip site navigation (1) Skip section navigation (2)

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

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <stark(at)mit(dot)edu>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Date: 2011-09-16 17:17:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Excerpts from Tom Lane's message of vie sep 16 13:37:46 -0300 2011:
> Greg Stark <stark(at)mit(dot)edu> writes:
> > On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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:

Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-09-16 17:25:17
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Previous:From: Tom LaneDate: 2011-09-16 16:37:46
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group