lkml.org 
[lkml]   [2011]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] mm: avoid livelock on !__GFP_FS allocations
    On Mon, 24 Oct 2011, Colin Cross wrote:

    > Under the following conditions, __alloc_pages_slowpath can loop
    > forever:
    > gfp_mask & __GFP_WAIT is true
    > gfp_mask & __GFP_FS is false
    > reclaim and compaction make no progress
    > order <= PAGE_ALLOC_COSTLY_ORDER
    >

    The oom killer is only called for __GFP_FS because we want to ensure that
    we don't inadvertently kill something if we didn't have a chance to at
    least make a good effort at direct reclaim. There's a very high liklihood
    that direct reclaim would succeed with __GFP_FS, so we loop endlessly
    waiting for either kswapd to reclaim in the background even though it
    might not be able to because of filesystem locks or another allocation
    happens in a context that allows reclaim to succeed or oom killing.

    For low-order allocations (those at or below PAGE_ALLOC_COSTLY_ORDER)
    where fragmentation isn't a huge issue, __GFP_WAIT && !__GFP_FS &&
    !did_some_progress makes sense.
    > These conditions happen very often during suspend and resume,
    > when pm_restrict_gfp_mask() effectively converts all GFP_KERNEL
    > allocations into __GFP_WAIT.
    >

    This is the problem. All allocations now have no chance of ever having
    direct reclaim succeed nor the oom killer called. It seems like you would
    want pm_restrict_gfp_mask() to also include __GFP_NORETRY and ensure it
    can never be called for __GFP_NOFAIL.

    > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
    > index fef8dc3..dcd99b3 100644
    > --- a/mm/page_alloc.c
    > +++ b/mm/page_alloc.c
    > @@ -2193,6 +2193,10 @@ rebalance:
    > }
    >
    > goto restart;
    > + } else {
    > + /* If we aren't going to try the OOM killer, give up */
    > + if (!(gfp_mask & __GFP_NOFAIL))
    > + goto nopage;
    > }
    > }
    >

    Nack on this, it is going to cause many very verbose allocation failures
    (if !__GFP_NOWARN) when not using suspend because we're not in a context
    where we can do sensible reclaim or compaction and presently kswapd can
    either reclaim or another allocation will allow low-order amounts of
    memory to be reclaimed or the oom killer to free some memory. It would
    introduce a regression into page allocation.


    \
     
     \ /
      Last update: 2011-10-26 00:13    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean