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.1002030131330.11389@chino.kir.corp.google.com>
Date:	Wed, 3 Feb 2010 01:40:58 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
cc:	Lubos Lunak <l.lunak@...e.cz>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Nick Piggin <npiggin@...e.de>, Jiri Kosina <jkosina@...e.cz>
Subject: Re: Improving OOM killer

On Wed, 3 Feb 2010, KOSAKI Motohiro wrote:

> Personally, I think your use case represent to typical desktop and Linux
> have to works fine on typical desktop use-case. /proc/pid/oom_adj never fit
> desktop use-case. In past discussion, I'v agreed with much people. but I haven't
> reach to agree with David Rientjes about this topic.
> 

Which point don't you agree with?  I've agreed that heuristic needs to be 
changed and since Kame has decided to abandon his oom killer work, I said 
that I would find time to develop a solution that would be based on 
consensus.  I don't think that simply replacing the baseline with rss, 
rendering oom_adj practically useless for any other purpose other than 
polarizing priorities, and removing any penalty for tasks that fork an 
egregious amount of tasks is acceptable to all parties, though.

When a desktop system runs a vital task that, at all costs, cannot 
possibly be oom killed such as KDE from the user perspective, is it really 
that outrageous of a request to set it to OOM_DISABLE?  No, it's not.  
There are plenty of open source examples of applications that tune their 
own oom_adj values for that reason; userspace input into the oom killer's 
heuristic will always be an integral part of its function.

I believe that we can reach consensus without losing the existing 
functionality that oom_adj provides, namely defining vital system tasks 
and memory leakers, and without this all or nothing type attitude that 
insists we either go with rss as a baseline because "it doesn't select X 
first in my particular example" or you'll just take your ball and go home.
--
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/