[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1312021508060.13465@chino.kir.corp.google.com>
Date: Mon, 2 Dec 2013 15:09:43 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Michal Hocko <mhocko@...e.cz>
cc: Luigi Semenzato <semenzato@...gle.com>, linux-mm@...ck.org,
Greg Thelen <gthelen@...gle.com>,
Glauber Costa <glommer@...il.com>,
Mel Gorman <mgorman@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Rik van Riel <riel@...hat.com>,
Joern Engel <joern@...fs.org>, Hugh Dickins <hughd@...gle.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: user defined OOM policies
On Thu, 28 Nov 2013, Michal Hocko wrote:
> > We already have hooks in the kernel oom killer, things like
> > /proc/sys/vm/oom_kill_allocating_task
>
> How would you implement oom_kill_allocating_task in userspace? You do
> not have any context on who is currently allocating or would you rely on
> reading /proc/*/stack to grep for allocation functions?
>
Not the exact behavior, sorry. I implemented oom_kill_allocating_task at
the request for SGI that simply wanted to avoid the lengthy tasklist scan,
they don't actually care what is killed as long as something is killed.
The actual allocating task is difficult to predict, especially in system
oom conditions, and their motivation was to make it as quickly as
possible. Userspace could certainly kill a random eligible process :)
--
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/
Powered by blists - more mailing lists