linux-kernel - Re: [PATCH] oom: skip frozen tasks

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.1108261110020.13943@chino.kir.corp.google.com>
Date:	Fri, 26 Aug 2011 11:13:40 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Michal Hocko <mhocko@...e.cz>
cc:	Oleg Nesterov <oleg@...hat.com>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [PATCH] oom: skip frozen tasks

On Fri, 26 Aug 2011, Michal Hocko wrote:

> > I do like the idea of automatically thawing the task though and if that's 
> > possible then I don't think we need to manipulate the badness heuristic at 
> > all.  I know that wouldn't be feasible when we've frozen _all_ threads and 
> 
> Why it wouldn't be feasible for all threads? If you have all tasks
> frozen (suspend going on, whole cgroup or all tasks in a cpuset/nodemask
> are frozen) then the selection is more natural because all of them are
> equal (with or without a bonus). The bonus tries to reduce thawing if
> not all of them are frozen.

Yeah, this comment wasn't in reference to your heuristic change, it was in 
reference to the fact that if all threads are frozen then there is little 
hope for us recovering from the situation without a user response.  I 
think that's why we want oom_killer_disable() so that we avoid looping 
forever and can actually fail allocations in the hope that we'll bring 
ourselves out of suspend.

> I am not saying the bonus is necessary, though. It depends on what
> the freezer is used for (e.g. freeze a process which went wild and
> debug what went wrong wouldn't welcome that somebody killed it or other
> (mis)use which relies on D state).
> 

I'd love to be able to do a thaw on a PF_FROZEN task in the oom killer 
followed by a SIGKILL if that task is selected for oom kill without an 
heuristic change.  Not sure if that's possible, so we'll wait for Rafael 
to chime in.

If it actually does come down to a heuristic change, then it need not 
happen in the oom killer: the freezing code would need to use 
test_set_oom_score_adj() to temporarily reduce the oom_score_adj for that 
task until it comes out of the refrigerator.  We already use that in ksm 
and swapoff to actually prefer threads, but we can use it to bias against 
threads as well.
--
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/