Re: System freezes after OOM

From: David Rientjes
Date: Mon Jul 18 2016 - 17:04:19 EST

On Mon, 18 Jul 2016, Michal Hocko wrote:

> > There's
> > two fundamental ways to go about it: (1) ensure mempool_alloc() can make
> > forward progress (whether that's by way of gfp flags or access to memory
> > reserves, which may depend on the process context such as PF_MEMALLOC) or
> > (2) rely on an implementation detail of mempools to never access memory
> > reserves, although it is shown to not livelock systems on 4.7 and earlier
> > kernels, and instead rely on users of the same mempool to return elements
> > to the freelist in all contexts, including oom contexts. The mempool
> > implementation itself shouldn't need any oom awareness, that should be a
> > page allocator issue.
> OK, I agree that we have a certain layer violation here. __GFP_NOMEMALLOC at
> the mempool level is kind of hack (like the whole existence of the
> flag TBH). So if you believe that the OOM part should be handled at the
> page allocator level then that has already been proposed
> and not welcome because it might have other side effects as _all_
> __GFP_NOMEMALLOC users would be affected.

__GFP_NOMEMALLOC is opt-in and is a workaround for PF_MEMALLOC in this
context to prevent a depletion of reserves, so it seems trivial to allow
mempool_alloc(__GFP_NOMEMALLOC) in contexts where it's needed and leave it
to the user.