Re: [patch] memcg: add oom killer delay

On Mon, 7 Mar 2011, Andrew Morton wrote:

quoted

So the question I'd ask is

What about my question?  Why is your usersapce oom-handler "unresponsive"?

If we have a per-memcg userspace oom handler, then it's absolutely 
required that it either increase the hard limit of the oom memcg or kill a 
task to free memory; anything else risks livelocking that memcg.  At 
the same time, the oom handler's memcg isn't really important: it may be 
in a different memcg but it may be oom at the same time.  If we risk 
livelocking the memcg when it is oom and the oom killer cannot respond 
(the only reason for the oom killer to exist in the first place), then 
there's no guarantee that a userspace oom handler could respond under 
livelock.

For users who don't choose to implement their own userspace oom handler, 
memory.oom_delay_millisecs could also be used to delay killing a task in a 
memcg unless it has reached the hard limit for only a specific period of 
time and doesn't rely on memory thresholds to signal the task to start 
freeing some of its own memory.

--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>