Re: [PATCH v2 0/4] memcg: Low-limit reclaim

[Michal Hocko]

On Wed 28-05-14 11:28:54, Johannes Weiner wrote:
> On Wed, May 28, 2014 at 04:21:44PM +0200, Michal Hocko wrote:
> > On Wed 28-05-14 09:49:05, Johannes Weiner wrote:
> > > On Wed, May 28, 2014 at 02:10:23PM +0200, Michal Hocko wrote:
[...]
> > > > My main motivation for the weaker model is that it is hard to see all
> > > > the corner case right now and once we hit them I would like to see a
> > > > graceful fallback rather than fatal action like OOM killer. Besides that
> > > > the usaceses I am mostly interested in are OK with fallback when the
> > > > alternative would be OOM killer. I also feel that introducing a knob
> > > > with a weaker semantic which can be made stronger later is a sensible
> > > > way to go.
> > > 
> > > We can't make it stronger, but we can make it weaker. 
> > 
> > Why cannot we make it stronger by a knob/configuration option?
> 
> Why can't we make it weaker by a knob?

I haven't said we couldn't.

> Why should we design the default for unforeseeable cornercases
> rather than make the default make sense for existing cases and give
> cornercases a fallback once they show up?

Sure we can do that but it would be little bit lame IMO. We are
promising something and once we find out it doesn't work we will make
it weaker to workaround that.

Besides that the default should reflect the usecases, no? Do we have any
use case for the hard guarantee?

> > > Stronger is the simpler definition, it's simpler code,
> > 
> > The code is not really that much simpler. The one you have posted will
> > not work I am afraid. I haven't tested it yet but I remember I had to do
> > some tweaks to the reclaim path to not end up in an endless loop in the
> > direct reclaim (http://marc.info/?l=linux-mm&m=138677140828678&w=2 and
> > http://marc.info/?l=linux-mm&m=138677141328682&w=2).
> 
> That's just a result of do_try_to_free_pages being stupid and using
> its own zonelist loop to check reclaimability by duplicating all the
> checks instead of properly using returned state of shrink_zones().
> Something that would be worth fixing regardless of memcg guarantees.
> 
> Or maybe we could add the guaranteed lru pages to sc->nr_scanned.

Fixes might be different than what I was proposing previously. I was
merely pointing out that removing the retry loop is not sufficient.

> > > your usecases are fine with it,
> > 
> > my usecases do not overcommit low_limit on the available memory, so far
> > so good, but once we hit a corner cases when limits are set properly but
> > we end up not being able to reclaim anybody in a zone then OOM sounds
> > too brutal.
> 
> What cornercases?

I have mentioned a case where NUMA placement and specific node bindings
interfering with other allocators can end up in unreclaimable zones.
While you might disagree about the setup I have seen different things
done out there.

Besides that the reclaim logic is complex enough and history thought me
that little buggers are hidden at places where you do not expect them.

So call me a chicken but I would sleep calmer if we start weaker and add
an additional guarantees later when somebody really insists on rseeing
an OOM rather than get reclaimed.
The proposed counter can tell us more how good we are at not touching
groups with the limit and we can eventually debug those corner cases
without affecting the loads too much.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/