linux-kernel - Re: Memory overcommit

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:	Tue, 3 Nov 2009 19:10:34 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
cc:	vedran.furac@...il.com, Hugh Dickins <hugh.dickins@...cali.co.uk>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	minchan.kim@...il.com, Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: Memory overcommit

On Wed, 4 Nov 2009, KAMEZAWA Hiroyuki wrote:

> My point and your point are differnt.
> 
>   1. All my concern is "baseline for heuristics"
>   2. All your concern is "baseline for knob, as oom_adj"
> 
> ok ? For selecting victim by the kernel, dynamic value is much more useful.
> Current behavior of "Random kill" and "Kill multiple processes" are too bad.
> Considering oom-killer is for what, I think "1" is more important.
> 
> But I know what you want, so, I offers new knob which is not affected by RSS
> as I wrote in previous mail.
> 
> Off-topic:
> As memcg is growing better, using OOM-Killer for resource control should be
> ended, I think. Maybe Fake-NUMA+cpuset is working well for google system, 
> but plz consider to use memcg. 
> 

I understand what you're trying to do, and I agree with it for most 
desktop systems.  However, I think that admins should have a very strong 
influence in what tasks the oom killer kills.  It doesn't really matter if 
it's via oom_adj or not, and its debatable whether an adjustment on a 
static heuristic score is in our best interest in the first place.  But we 
must have an alternative so that our control over oom killing isn't lost.

I'd also like to open another topic for discussion if you're proposing 
such sweeping changes: at what point do we allow ~__GFP_NOFAIL allocations 
to fail even if order < PAGE_ALLOC_COSTLY_ORDER and defer killing 
anything?  We both agreed that it's not always in the best interest to 
kill a task so that an allocation can succeed, so we need to define some 
criteria to simply fail the allocation instead.

> Old processes are important, younger are not. But as I wrote, I'll drop
> most of patch "6". So, plz forget about this part.
> 
> I'm interested in fork-bomb killer rather than crazy badness calculation, now.
> 

Ok, great.  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/