On Fri, Apr 20, 2012 at 4:15 PM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > On Fri, Apr 20, 2012 at 11:22:14AM -0700, Ying Han wrote: >> On Fri, Apr 20, 2012 at 2:17 AM, Michal Hocko <mhocko@xxxxxxx> wrote: >> > On Tue 17-04-12 09:38:02, Ying Han wrote: >> >> This patch reverts all the existing softlimit reclaim implementations and >> >> instead integrates the softlimit reclaim into existing global reclaim logic. >> >> >> >> The new softlimit reclaim includes the following changes: >> >> >> >> 1. add function should_reclaim_mem_cgroup() >> >> >> >> Add the filter function should_reclaim_mem_cgroup() under the common function >> >> shrink_zone(). The later one is being called both from per-memcg reclaim as >> >> well as global reclaim. >> >> >> >> Today the softlimit takes effect only under global memory pressure. The memcgs >> >> get free run above their softlimit until there is a global memory contention. >> >> This patch doesn't change the semantics. >> > >> > I am not sure I understand but I think it does change the semantics. >> > Previously we looked at a group with the biggest excess and reclaim that >> > group _hierarchically_. >> >> yes, we don't do _hierarchically_ reclaim reclaim in this patch. Hmm, >> that might be what Johannes insists to preserve on the other >> thread.... ? > > Yes, that is exactly what I was talking about all along :-) > > To reiterate, in the case of > > A (soft = 10G) > A1 > A2 > A3 > ... > > global reclaim should go for A, A1, A2, A3, ... when their sum usage > goes above 10G. Regardless of any setting in those subgroups, for > reasons I outlined in the other subthread (basically, allowing > children to override parental settings assumes you trust all children > and their settings to be 'cooperative', which is unprecedented cgroup > semantics, afaics, and we can already see this will make problems in > the future) I understand your concern here. Having children to override the parental setting is not what we want, but I think this is a mis-configuration. If admin chose to use soft_limit, we need to lay out the ground rule. I gave some details on the other thread, maybe we can move the conversation there :) > > Meanwhile, if you don't want a hierarchical limit, don't set a > hierarchical limit. It's possible to organize the tree such that you > don't need to, and it should not be an unreasonable amount of work to > do so). Not setting it won't work either way. 1. unlimited: it will never get the pages under A being reclaimed 2. 0: it will get everything being reclaimed under A based on your logic. Have a nice weekend ! --Ying > > -- > 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> -- 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