linux-kernel - Re: Improving OOM killer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1002031220070.750@chino.kir.corp.google.com>
Date:	Wed, 3 Feb 2010 12:26:19 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Frans Pop <elendil@...net.nl>
cc:	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Rik van Riel <riel@...hat.com>, l.lunak@...e.cz,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Nick Piggin <npiggin@...e.de>, jkosina@...e.cz,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: Improving OOM killer

On Wed, 3 Feb 2010, Frans Pop wrote:

> That doesn't take into account:
> - applications where the oom_adj value is hardcoded to a specific value
>   (for whatever reason)
> - sysadmin scripts that set oom_adj from the console
> 

The fundamentals are the same: negative values mean the task is less 
likely to be preferred and positive values mean the task is more likely, 
only the scale is different.  That scale is exported by the kernel via 
OOM_ADJUST_MIN and OOM_ADJUST_MAX and has been since 2006.  I don't think 
we need to preserve legacy applications or scripts that use hardcoded 
values without importing linux/oom.h.

> I would think that oom_adj is a documented part of the userspace ABI and 
> that the change you propose does not fit the normal backwards 
> compatibility requirements for exposed tunables.
> 

The range is documented (but it should have been documented as being from 
OOM_ADJUST_MIN to OOM_ADJUST_MAX) but its implementation as a bitshift is 
not; it simply says that positive values mean the task is more preferred 
and negative values mean it is less preferred.  Those semantics are 
preserved.

> I think that at least any user who's currently setting oom_adj to -17 has a 
> right to expect that to continue to mean "oom killer disabled". And for 
> any other value they should get a similar impact to the current impact, 
> and not one that's reduced by a factor 66.
> 

If the baseline changes as we all agree it needs to such that oom_adj no 
longer represents the same thing it did in the first place (it would 
become a linear bias), I think this breakage is actually beneficial.  
Users will now be able to tune their oom_adj values based on a fraction of 
system memory to bias their applications either preferrably or otherwise.

I think we should look at Linux over the next couple of years and decide 
if we want to be married to the current semantics of oom_adj that are 
going to change (as it would require being a factor of 66, as you 
mentioned) when the implementation it was designed for has vanished.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/