RE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module

[<leonid.moiseichuk@nokia.com>]

> -----Original Message-----
> From: ext David Rientjes [mailto:rientjes@google.com]
> 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@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>