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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Date: 2011-09-18 16:21:08
Message-ID: 15953.1316362868@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On fre, 2011-09-16 at 10:57 -0400, Tom Lane wrote:
>> So it looks like it behooves us to cater for oom_score_adj in the
>> future. The simplest, least risky change that I can think of is to
>> copy-and-paste the relevant #ifdef code block in fork_process.c.
>> If we do that, then it would be up to the packager whether to #define
>> LINUX_OOM_ADJ or LINUX_OOM_SCORE_ADJ or both depending on the behavior
>> he wants.

> There are lots of reasons why that won't work: backports, forward ports,
> derivatives, custom kernels, distribution upgrades, virtual hosting.

[ shrug... ] These are all hypothetical reasons. A packager who
foresaw needing that could just turn on both write attempts, or for that
matter patch the code to do whatever else he saw fit. In practice,
we've not had requests for anything significantly smarter than what is
there.

But having said that, it wouldn't be very hard to arrange things so that
if you did have both symbols defined, the code would only attempt to
write oom_adj if it had failed to write oom_score_adj; which is about as
close as you're likely to get to a kernel version test for this.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-09-18 16:43:32 Re: Is there really no interest in SQL Standard?
Previous Message Erik Rijkers 2011-09-18 16:08:22 Re: Range Types - typo + NULL string constructor