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

On Thu, 6 Jan 2011 11:16:00 +0530
Balbir Singh [off-list ref] wrote:

* KAMEZAWA Hiroyuki [off-list ref] [2011-01-06 10:53:15]:

quoted

quoted

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>