linux-kernel - Re: [BUGFIX][PATCH] oom-kill: fix NUMA consraint check with nodemask v4.2

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.0912142054520.436@chino.kir.corp.google.com>
Date:	Mon, 14 Dec 2009 20:57:53 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Daisuke Nishimura <nishimura@....nes.nec.co.jp>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [BUGFIX][PATCH] oom-kill: fix NUMA consraint check with nodemask
 v4.2

On Tue, 15 Dec 2009, KAMEZAWA Hiroyuki wrote:

> > That's not at all what I said.  I said using total_vm as a baseline allows 
> > users to define when a process is to be considered "rogue," that is, using 
> > more memory than expected.  Using rss would be inappropriate since it is 
> > highly dynamic and depends on the state of the VM at the time of oom, 
> > which userspace cannot possibly keep updated.
> > 
> > You consistently ignore that point: the power of /proc/pid/oom_adj to 
> > influence when a process, such as a memory leaker, is to be considered as 
> > a high priority for an oom kill.  It has absolutely nothing to do with 
> > fake NUMA, cpusets, or memcg.
> > 
> You also ignore that it's not sane to use oom kill for resource control ;)
> 

Please read my email.  Did I say anything about resource control AT ALL?  
I said /proc/pid/oom_adj currently allows userspace to define when a task 
is "rogue," meaning its consuming much more memory than expected.  Those 
memory leakers should always be the optimal result for the oom killer to 
kill.  Using rss as the baseline would not allow userspace to effectively 
do the same thing since it's dynamic and depends on the state of the VM at 
the time of oom which is probably not reflected in the /proc/pid/oom_adj 
values for all tasks.  It has absolutely nothing to do with resource 
control, so please address this very trivial issue without going off on 
tangents.  Thanks.
--
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/