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

On Tue, Jul 1, 2014 at 8:22 AM, Christoph Berg <cb(at)df7cb(dot)de> wrote:
> Re: Tom Lane 2014-06-23 <17054(dot)1403542164(at)sss(dot)pgh(dot)pa(dot)us>
>> > While I'd love to reduce the number of future installations without
>> > this fix in place, I respect the decision to honor project policy. At
>> > the same time, this change does not break anything. It introduces new
>> > environment variables which change the behaviour, but behaves the old
>> > way in the absence of those variables.
>>
>> Uh, no, it doesn't. We removed the dependence on -DLINUX_OOM_SCORE_ADJ.
>> If a packager is expecting that to still work in 9.4, he's going to be
>> unpleasantly surprised, because the system will silently fail to do what
>> he's expecting: it will run all the backend processes at no-OOM-kill
>> priority, which is likely to be bad.
>
> Ok I'm late to the party, but the reason I'm still joining is we have
> proper unit tests which just told me the 9.5 packages have changed OOM
> handling. So it wouldn't just slip through if you changed that in 9.4
> as well, but would get fixed.
>
> I have two comments on the patch:
>
> The choice to make the behavior depend first on PG_OOM_ADJUST_FILE and
> only secondly on PG_OOM_ADJUST_VALUE seems the wrong way round to me.
> On every modestly new kernel oom_score_adj is present, so
> PG_OOM_ADJUST_FILE should default to using it. On the other hand, what
> people really want to achieve (or tune) with this feature is to set
> the OOM adjustment back to 0 (or some other value), so to me, it would
> be much more natural to set PG_OOM_ADJUST_VALUE=0 to activate the
> feature, and only have to mess with PG_OOM_ADJUST_FILE if my kernel is
> older. (Which it isn't on any kernel supported by Debian and Ubuntu
> LTS.)

Of course, we have no guarantee that the Linux kernel guys won't
change this again. Apparently "we don't break userspace" is a
somewhat selectively-enforced principle.

> The other bit is the non-deprecation of OOM_ADJ in
> contrib/start-scripts/linux. It took me a while to understand the
> logic of the variables used there - the interface would be much
> clearer if it just was like this:
>
> ... set default PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
>
> ... and then this in the configurable part of the script:
>
> PG_MASTER_OOM_SCORE_ADJ=-1000
> PG_OOM_SCORE_ADJ=0
> # Older Linux kernels may not have /proc/self/oom_score_adj, but instead
> # /proc/self/oom_adj, which works similarly except the disable value is -17.
> # For such a system, uncomment these three lines instead.
> #PG_OOM_ADJUST_FILE=/proc/self/oom_adj
> #PG_MASTER_OOM_SCORE_ADJ=-17
> #PG_OOM_SCORE_ADJ=0
>
> ... and then use PG_OOM_ADJUST_FILE below instead of manually figuring
> out which proc file to write to by looking at OOM.*_ADJ.

I can't help but agree with this, though.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company