lkml.org 
[lkml]   [2014]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/2] mm, memcg: avoid oom notification when current needs access to memory reserves
On Wed, 15 Jan 2014, Michal Hocko wrote:

> > > > > > It was acked-by Michal.
> > >
> > > Michal acked it before we had most of the discussions and now he is
> > > proposing an alternate version of yours, a patch that you are even
> > > discussing with him concurrently in another thread. To claim he is
> > > still backing your patch because of that initial ack is disingenuous.
> > >
> >
> > His patch depends on mine, Johannes.
>
> Does it? Are we talking about the same patch here?
> https://lkml.org/lkml/2013/12/12/174
>

I'm happy with either patch, I suggested doing the mem_cgroup_oom_notify()
at the last minute only when actually killing a process because of your
concern that the oom killer would still defer. That was addressing your
concern as an extension of my patch which avoids unconditionally giving
current access to memory reserves without scanning or deferring anything.
I would be happy with either approach, and so I don't see why removing my
patch from -mm which yours is based on would be needed.

> Which depends on yours only to revert your part. I plan to repost it but
> that still doesn't mean it will get merged because Johannes still has
> some argumnets against. I would like to start the discussion again
> because now we are so deep in circles that it is hard to come up with a
> reasonable outcome. It is still hard to e.g. agree on an actual fix
> for a real problem https://lkml.org/lkml/2013/12/12/129.
>

This is concerning because it's merged in -mm without being tested by Eric
and is marked for stable while violating the stable kernel rules criteria.


\
 
 \ /
  Last update: 2014-01-15 23:01    [W:0.154 / U:0.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site