lkml.org 
[lkml]   [2011]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] mm: avoid livelock on !__GFP_FS allocations
    From
    On Tue, Oct 25, 2011 at 9:39 AM, Colin Cross <ccross@android.com> 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
    >
    > These conditions happen very often during suspend and resume,
    > when pm_restrict_gfp_mask() effectively converts all GFP_KERNEL
    > allocations into __GFP_WAIT.

    Why does it do that? Why don't we fix the gfp mask instead?

    > The oom killer is not run because gfp_mask & __GFP_FS is false,
    > but should_alloc_retry will always return true when order is less
    > than PAGE_ALLOC_COSTLY_ORDER.
    >
    > Fix __alloc_pages_slowpath to skip retrying when oom killer is
    > not allowed by the GFP flags, the same way it would skip if the
    > oom killer was allowed but disabled.
    >
    > Signed-off-by: Colin Cross <ccross@android.com>
    > ---
    >
    > An alternative patch would add a did_some_progress argument to
    > __alloc_pages_may_oom, and remove the checks in
    > __alloc_pages_slowpath that require knowledge of when
    > __alloc_pages_may_oom chooses to run out_of_memory. If
    > did_some_progress was still zero, it would goto nopage whether
    > or not __alloc_pages_may_oom was actually called.
    >
    >  mm/page_alloc.c |    4 ++++
    >  1 files changed, 4 insertions(+), 0 deletions(-)
    >
    > 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;
    >                }
    >        }

    I don't quite understand how __GFP_WAIT is involved here. Which path
    is causing the infinite loop?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-10-25 09:43    [W:0.024 / U:126.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site