On Sat 21-04-12 01:29:09, Johannes Weiner wrote: > On Fri, Apr 20, 2012 at 08:58:47PM +0200, Michal Hocko wrote: > > On Fri 20-04-12 10:44:14, Ying Han wrote: > > > On Fri, Apr 20, 2012 at 6:17 AM, Johannes Weiner <hannes@xxxxxxxxxxx> 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 ;) > > Thanks for the nice summary! > > A note on the default hierarchical soft limit: > > Consider not making the default to be 0, but a special value. We want > it to mean 'no guarantee' and 'every byte is in excess of the soft > limit', to keep the existing behaviour. But at the same time, we > wouldn't have to make it inheritable: > > A (soft = default) > A1 (soft = 10G) > A2 (soft = 12G) > > so in case of global reclaim, A itself would be eligible, but it would > not apply hierarchically to A1 and A2. They would still only get > reclaimed if their usage would be above their respective soft limits. > Only if you set A's soft limit to 0 or higher it will apply > hierarchically, so that if a parent declares 'no guarantee', no child > is able to override it. I was thinking about a special value for the local reclaim as well but I didn't like it much because then it wouldn't be only a value for limit but also an API to switch between hierarchical vs. non-hierarchical reclaim so it is an API of some sort. So I am really not so sure about it and would rather go a different way - if there is any... > Maybe we can keep -1/~0UL and just treat it a bit differently. I would rather see 0 as a special value, if this is the only way to go, it would make the life easier and also it makes more sense to me. -- 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@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>