> -----Original Message----- > From: ext David Rientjes [mailto:rientjes@xxxxxxxxxx] > Sent: 09 January, 2012 21:55 ... > > Maybe there's some confusion: the proposed oom killer delay that I'm > referring to here is not upstream and has never been written for global oom > conditions. My reference to it earlier was as an internal patch that we carry > on top of memory controller, but what I'm proposing here is for it to be > implemented globally. That is explains situation - I know how memcg can handle OOM in cgroup but not about internal patch. > So if the page allocator can make no progress in freeing memory, we would > introduce a delay in out_of_memory() if it were configured via a sysctl from > userspace. When this delay is started, applications waiting on this event can > be notified with eventfd(2) that the delay has started and they have > however many milliseconds to address the situation. When they rewrite the > sysctl, the delay is cleared. If they don't rewrite the sysctl and the delay > expires, the oom killer proceeds with killing. > > What's missing for your use case with this proposal? Timed delays in multi-process handling in case OOM looks for me fragile construction due to delays are not predicable. Memcg supports [1] better approach to freeze whole group and kick pointed user-space application to handle it. We planned to use it as: - enlarge cgroup - send SIGTERM to selected "bad" application e.g. based on oom_score - wait a bit - send SIGKILL to "bad" application - reduce group size But finally default OOM killer starts to work fine. [1] http://lwn.net/Articles/377708/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. 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