lkml.org 
[lkml]   [2015]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 12/12] mm: page_alloc: do not lock up low-order allocations upon OOM
    On Wed 25-03-15 02:17:16, Johannes Weiner wrote:
    > When both page reclaim and the OOM killer fail to free memory, there
    > are no more options for the allocator to make progress on its own.
    >
    > Don't risk hanging these allocations. Leave it to the allocation site
    > to implement the fallback policy for failing allocations.

    The changelog communicates the impact of this patch _very_ poorly. The
    potential regression space is quite large. Every syscall which is not
    allowed to return ENOMEM and it relies on an allocation would have to be
    audited or a common mechanism to catch them deployed.

    I really believe this is a good thing _longterm_ but I still do not
    think it is the upstream material anytime soon without extensive testing
    which is even not mentioned here.

    > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    > ---
    > mm/page_alloc.c | 19 ++++++-------------
    > 1 file changed, 6 insertions(+), 13 deletions(-)
    >
    > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
    > index 9e45e97aa934..f2b1a17416c4 100644
    > --- a/mm/page_alloc.c
    > +++ b/mm/page_alloc.c
    > @@ -2331,12 +2331,10 @@ void warn_alloc_failed(gfp_t gfp_mask, int order, const char *fmt, ...)
    >
    > static inline struct page *
    > __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, int alloc_flags,
    > - const struct alloc_context *ac, unsigned long *did_some_progress)
    > + const struct alloc_context *ac)
    > {
    > struct page *page = NULL;
    >
    > - *did_some_progress = 0;
    > -
    > /*
    > * This allocating task can become the OOM victim itself at
    > * any point before acquiring the lock. In that case, exit
    > @@ -2376,13 +2374,9 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, int alloc_flags,
    > goto out;
    > }
    >
    > - if (out_of_memory(ac->zonelist, gfp_mask, order, ac->nodemask, false)) {
    > - *did_some_progress = 1;
    > - } else {
    > + if (!out_of_memory(ac->zonelist, gfp_mask, order, ac->nodemask, false))
    > /* Oops, these shouldn't happen with the OOM killer disabled */
    > - if (WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL))
    > - *did_some_progress = 1;
    > - }
    > + WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL);
    >
    > /*
    > * Allocate from the OOM killer reserves.
    > @@ -2799,13 +2793,12 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
    > }
    >
    > /* Reclaim has failed us, start killing things */
    > - page = __alloc_pages_may_oom(gfp_mask, order, alloc_flags, ac,
    > - &did_some_progress);
    > + page = __alloc_pages_may_oom(gfp_mask, order, alloc_flags, ac);
    > if (page)
    > goto got_pg;
    >
    > - /* Retry as long as the OOM killer is making progress */
    > - if (did_some_progress)
    > + /* Wait for user to order more dimms, cuz these are done */
    > + if (gfp_mask & __GFP_NOFAIL)
    > goto retry;
    >
    > noretry:
    > --
    > 2.3.3
    >

    --
    Michal Hocko
    SUSE Labs


    \
     
     \ /
      Last update: 2015-03-26 16:41    [W:4.483 / U:0.216 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site