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: | 1316192401-sup-4726@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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:
https://github.com/mirrors/linux-2.6/commit/a63d83f427fbce97a6cea0db2e64b0eb8435cd10#include/linux/oom.h
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-09-16 17:25:17 | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
Previous Message | Tom Lane | 2011-09-16 16:37:46 | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |