On Thu, 10 Feb 2011, KAMEZAWA Hiroyuki wrote: > Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> > Thanks! > Hm. But I'm not sure how this will be used. > Since this patch hasn't been added to -mm even with your acked-by, I'm assuming Andrew is waiting for an answer to this :) I thought it was fairly well covered in the changelog, but I'll elaborate: We can already give userspace a grace period to act before oom killing a task by utilizing memory.oom_control. That's not what the oom killer delay addresses, however. This addresses a very specific (and real) problem that occurs when userspace wants that grace period but is unable to respond, for whatever reason, to either increase the hard limit or allow the oom kill to proceed. The possibility of that happening would cause that memcg to livelock because no forward progress could be made when oom, which is a negative result. We don't have that possibility with the global oom killer since the kernel will always choose to act if memory freeing is not imminent: in other words, since we've opened the window for livelock because of an unreliable userspace via a kernel feature -- namely memory.oom_control -- then it's only responsible to provide an alternate means to configure the cgroup for the same grace period without risking livelock. -- 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 internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>