[lkml]   [2013]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 1/2] mm, memcg: avoid oom notification when current needs access to memory reserves
On Fri, 22 Nov 2013, Johannes Weiner wrote:

> But userspace in all likeliness DOES need to take action.
> Reclaim is a really long process. If 5 times doing 12 priority cycles
> and scanning thousands of pages is not enough to reclaim a single
> page, what does that say about the health of the memcg?
> But more importantly, OOM handling is just inherently racy. A task
> might receive the kill signal a split second *after* userspace was
> notified. Or a task may exit voluntarily a split second after a
> victim was chosen and killed.

That's not true even today without the userspace oom handling proposal
currently being discussed if you have a memcg oom handler attached to a
parent memcg with access to more memory than an oom child memcg. The oom
handler can disable the child memcg's oom killer with memory.oom_control
and implement its own policy to deal with any notification of oom.

This patch is required to ensure that in such a scenario that the oom
handler sitting in the parent memcg only wakes up when it's required to
intervene. Making an inference about the "health of the memcg" can
certainly be done with memory thresholds and vmpressure, if you need that.

I agree with Michal.

 \ /
  Last update: 2013-11-27 07:01    [W:0.095 / U:1.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site