Re: [patch v3] memcg: add oom killer delay

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Thu, 6 Jan 2011 11:16:00 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [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@kvack.org.  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@kvack.org"> email@kvack.org </a>