* KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> [2011-01-06 10:53:15]: > > Kamezawa-San, not sure if your comment is clear, are you suggesting > > > > Since memcg is the root of a hierarchy, we need to use hierarchical > > locking before changing the value of the root oom_delay? > > > > No. mem_cgroup_oom_lock() is a lock for hierarchy, not for a group. > > For example, > > A > / \ > B C > > In above hierarchy, when C is in OOM, A's OOM will be blocked by C's OOM. > Because A's OOM can be fixed by C's oom-kill. > This means oom_delay for A should be for C (and B), IOW, for hierarchy. > > > A and B, C should have the same oom_delay, oom_disable value. > Why so? You already mentioned that A's OOM will be blocked by C's OOM? If we keep that behaviour, if C has a different oom_delay value, it won't matter, since we'll never go up to A. If the patch breaks that behaviour then we are in trouble. With hierarchy we need to ensure that if A has a oom_delay set and C does not, A's setting takes precendence. In the absence of that logic what you say makes sense. > About oom_disable, > - It can be set only when A has no children and root of hierarchy. > - It's inherited at creating children. > > Then, A, B ,C have the same value. > > Considering race conditions, I like current oom_disable's approach. > Thanks for clarifying. -- Three Cheers, Balbir -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>