[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1401101335200.21486@chino.kir.corp.google.com>
Date: Fri, 10 Jan 2014 13:38:50 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Michal Hocko <mhocko@...e.cz>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
cgroups@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [patch 1/2] mm, memcg: avoid oom notification when current needs
access to memory reserves
On Fri, 10 Jan 2014, Michal Hocko wrote:
> I have already explained why I have acked it. I will not repeat
> it here again. I have also proposed an alternative solution
> (https://lkml.org/lkml/2013/12/12/174) which IMO is more viable because
> it handles both user/kernel memcg OOM consistently. This patch still has
> to be discussed because of other Johannes concerns. I plan to repost it
> in a near future.
>
This three ring circus has to end. Really.
Your patch, which is partially based on my suggestion to move the
mem_cgroup_oom_notify() and call it from two places to support both
memory.oom_control == 1 and != 1, is something that I liked as you know.
It's based on my patch which is now removed from -mm. So if you want to
rebase that patch and propose it, that's great, but this is yet another
occurrence of where important patches have been yanked out just before the
merge window when the problem they are fixing is real and we depend on
them.
Please post your rebased patch ASAP for the 3.14 merge window.
--
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