lkml.org 
[lkml]   [2013]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: user defined OOM policies
Hi David

On Wed, Nov 20, 2013 at 12:02:20AM -0800, David Rientjes wrote:
> On Tue, 19 Nov 2013, Michal Hocko wrote:
>
> > > We have basically ended up with 3 options AFAIR:
> > > 1) allow memcg approach (memcg.oom_control) on the root level
> > > for both OOM notification and blocking OOM killer and handle
> > > the situation from the userspace same as we can for other
> > > memcgs.
> >
> > This looks like a straightforward approach as the similar thing is done
> > on the local (memcg) level. There are several problems though.
> > Running userspace from within OOM context is terribly hard to do
> > right.
>
> Not sure it's hard if you have per-memcg memory reserves which I've
> brought up in the past with true and complete kmem accounting. Even if
> you don't allocate slab, it guarantees that there will be at least a
> little excess memory available so that the userspace oom handler isn't oom
> itself.
>
> This involves treating processes waiting on memory.oom_control to be
> treated as a special class so that they are allowed to allocate an
> additional pre-configured amount of memory. For non-root memcgs, this
> would simply be a dummy usage that would be charged to the memcg when the
> oom notification is registered and actually accessible only by the oom
> handler itself while memcg->under_oom. For root memcgs, this would simply
> be a PF_MEMALLOC type behavior that dips into per-zone memory reserves.
>
> > This is true even in the memcg case and we strongly discurage
> > users from doing that. The global case has nothing like outside of OOM
> > context though. So any hang would blocking the whole machine.
>
> Why would there be a hang if the userspace oom handlers aren't actually
> oom themselves as described above?
>
> I'd suggest against the other two suggestions because hierarchical
> per-memcg userspace oom handlers are very powerful and can be useful
> without actually killing anything at all, and parent oom handlers can
> signal child oom handlers to free memory in oom conditions (in other
> words, defer a parent oom condition to a child's oom handler upon

Is not vmpressure notifications was designed for that purpose?

Vladimir

> notification). I was planning on writing a liboom library that would lay
> the foundation for how this was supposed to work and some generic
> functions that make use of the per-memcg memory reserves.
>
> So my plan for the complete solution was:
>
> - allow userspace notification from the root memcg on system oom
> conditions,
>
> - implement a memory.oom_delay_millisecs timeout so that the kernel
> eventually intervenes if userspace fails to respond, including for
> system oom conditions, for whatever reason which would be set to 0
> if no userspace oom handler is registered for the notification, and
>
> - implement per-memcg reserves as described above so that userspace oom
> handlers have access to memory even in oom conditions as an upfront
> charge and have the ability to free memory as necessary.
>
> We already have the ability to do the actual kill from userspace, both the
> system oom killer and the memcg oom killer grants access to memory
> reserves for any process needing to allocate memory if it has a pending
> SIGKILL which we can send from userspace.
>
> --
> 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/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>


\
 
 \ /
  Last update: 2013-11-21 02:21    [W:0.161 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site