On Thu, 6 Jan 2011 11:16:00 +0530 Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote: > * 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. When C's oom_delay is 10min and A's oom_delay is 1min, A can be blocked for 10min even if it has 1min delay. I don't want this complex rule. > 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. > His implemenation doesn't do that and I want a simple one even if I have to make an Ack to a feature which seems of-no-use to me. Thanks, -Kame -- 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>