lkml.org 
[lkml]   [2016]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: System freezes after OOM
    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
    > http://lkml.kernel.org/r/2d5e1f84-e886-7b98-cb11-170d7104fd13@I-love.SAKURA.ne.jp
    > 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.

    \
     
     \ /
      Last update: 2016-07-18 23:41    [W:3.965 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site