[lkml]   [2013]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] mm, memcg: add memory.oom_control notification for system oom
On Wed, 13 Nov 2013, Johannes Weiner wrote:

> > > Somebody called out_of_memory() after they
> > > failed reclaim, the machine is OOM.
> >
> > While momentarily oom, the oom notifiers in powerpc and s390 have the
> > ability to free memory without requiring a kill.
> So either
> 1) they should be part of the regular reclaim process, or
> 2) their invocation is severe enough to not be part of reclaim, at
> which point we should probably tell userspace about the OOM

(1) is already true, we can avoid oom by freeing memory for subsystems
using register_oom_notifier(), so we're not actually oom. It's a late
callback into the kernel to free memory in a sense of reclaim. It was
added directly into out_of_memory() purely for simplicity; it could be
moved to the page allocator if we move all of the oom_notify_list helpers
there as well.

The same is true of silently setting TIF_MEMDIE for current so that it has
access to memory reserves and may exit when it has a pending SIGKILL or is
already exiting.

In both cases, we're not actually oom because either (a) the kernel can
still free memory and avoid actually killing a process, or (b) current
simply needs access to memory reserves so it may die.

We don't want to invoke the userspace oom handler when we first enter
direct reclaim, for example, for the same reason.

> > I think you're misunderstanding the kernel oom notifiers, they exist
> > solely to free memory so that the oom killer actually doesn't have to kill
> > anything. The fact that they use kernel notifiers is irrelevant and
> > userspace oom notification is separate. Userspace is only going to want a
> > notification when the oom killer has to kill something, the EXACT same
> > semantics as the non-root-memcg memory.oom_control.
> That's actually not true, we invoke the OOM notifier before calling
> mem_cgroup_out_of_memory(), which then may skip the kill in favor of
> letting current exit. It does this for when the kernel handler is
> enabled, which would be the equivalent for what you are implementing.

Good point, I don't think we should be notifying userspace for memcg oom
conditions when current simply needs access to memory reserves to exit:
the memcg isn't actually oom since TIF_MEMDIE implies memcg bypass. I
think we should do that in mem_cgroup_handle_oom() rather than

 \ /
  Last update: 2013-11-15 00:41    [W:0.137 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site