Re: [PATCH V3 0/2] memcg softlimit reclaim rework

[Michal Hocko <mhocko@suse.cz>]

On Fri 20-04-12 10:44:14, Ying Han wrote:
> On Fri, Apr 20, 2012 at 6:17 AM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> > Let me repeat the pros here: no breaking of existing semantics.  No
> > introduction of unprecedented semantics into the cgroup mess.  No
> > changing of kernel code necessary (except what we want to tune
> > anyway).  No computational overhead for you or anyone else.
> 
> >
> > If your only counter argument to this is that you can't be bothered to
> > slightly adjust your setup, I'm no longer interested in this
> > discussion.
> 
> Before going further, I wanna make sure there is no mis-communication
> here. As I replied to Michal, I feel that we are mixing up global
> reclaim and target reclaim policy here.

I was referring to the global reclaim and my understanding is that
Johannes did the same when talking about soft reclaim (even though it
makes some sense to apply the same rules to the hard limit reclaim as
well - but later to that one...)

The primary question is whether soft reclaim should be hierarchical or
not. That is what I've tried to express in other email earlier in this
thread where I've tried (very briefly) to compare those approaches.
It currently _is_ hierarchical and your patch changes that so we have to
be sure that this change in semantic is reasonable. The only workload
that you seem to consider is when you have a full control over the
machine while Johannes is considered about containers which might misuse
your approach to push out working sets of concurrency...
My concern with hierarchical approach is that it doesn't play well with
0 default (which is needed if we want to make soft limit a guarantee,
right?). I do agree with Johannes about the potential misuse though.  So
it seems that both approaches have serious issues with configurability.
Does this summary clarify the issue a bit? Or I am confused as well ;)

I am more inclined towards selective soft reclaim and make configuration
admin's responsibility (if you want some guarantee, admin has to approve
that and set it for you). This, however, doesn't enable self-ballooning
use case but I am not entirely sure this would work without a global
(admin) cooperation.

> The way global reclaim works today is to scan all the mem cgroups to
> fulfill the overall scan target per zone, and there is no bottom up
> look up. 

bottom up was just an idea without anything in hands so let's put it
aside for now.

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>