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 17:58:04 -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:

> > That's a different point.  Today, we can influence the badness score of 
> > any user thread to prioritize oom killing from userspace and that can be 
> > done regardless of whether there's a memory leaker, a fork bomber, etc.  
> > The priority based oom killing is important to production scenarios and 
> > cannot be replaced by a heuristic that works everytime if it cannot be 
> > influenced by userspace.
> > 
> I don't removed oom_adj...
> 

Right, but we must ensure that we have the same ability to influence a 
priority based oom killing scheme from userspace as we currently do with a 
relatively static total_vm.  total_vm may not be the optimal baseline, but 
it does allow users to tune oom_adj specifically to identify tasks that 
are using more memory than expected and to be static enough to not depend 
on rss, for example, that is really hard to predict at the time of oom.

That's actually my main goal in this discussion: to avoid losing any 
ability of userspace to influence to priority of tasks being oom killed 
(if you haven't noticed :).

> > Tweaking on the heuristic will probably make it more convoluted and 
> > overall worse, I agree.  But it's a more stable baseline than rss from 
> > which we can set oom killing priorities from userspace.
> 
> - "rss < total_vm_size" always.

But rss is much more dynamic than total_vm, that's my point.

> - oom_adj culculation is quite strong.
> - total_vm of processes which maps hugetlb is very big ....but killing them
>   is no help for usual oom.
> 
> I recommend you to add "stable baseline" knob for user space, as I wrote.
> My patch 6 adds stable baseline bonus as 50% of vm size if run_time is enough
> large.
> 

There's no clear relationship between VM size and runtime.  The forkbomb 
heuristic itself could easily return a badness of ULONG_MAX if one is 
detected using runtime and number of children, as I earlier proposed, but 
that doesn't seem helpful to factor into the scoring. 
--
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/