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]
Date:	Thu, 11 Feb 2010 13:01:56 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Nick Bowler <nbowler@...iptictech.com>
cc:	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Nick Piggin <npiggin@...e.de>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Lubos Lunak <l.lunak@...e.cz>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [patch 4/7 -mm] oom: badness heuristic rewrite

On Thu, 11 Feb 2010, Nick Bowler wrote:

> > As mentioned in the changelog, we've exported these minimum and maximum 
> > values via a kernel header file since at least 2006.  At what point do we 
> > assume they are going to be used and not hardcoded into applications?  
> > That was certainly the intention when making them user visible.
> 
> The thing is, even when the macros are used, their values are hardcoded
> into programs once the code is run through a compiler.  That's why it's
> called an ABI.
> 

Right, that's the second point that I listed: since the semantics of the 
tunable have radically changed from the bitshift to an actual unit 
(proportion of available memory), those applications need to change how 
they use oom_adj anyway.  The bitshift simply isn't extendable with any 
sane heuristic that is predictable or works with any reasonable amount of 
granularity, so this change seems inevitable in the long term.

We may be forced to abandon /proc/pid/oom_adj itself and introduce the 
tunable with a different name: oom_score_adj, for example, to make it 
clear that it's a different entity.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ