Skip to content
  • Michal Hocko's avatar
    mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic · dcda9b04
    Michal Hocko authored
    __GFP_REPEAT was designed to allow retry-but-eventually-fail semantic to
    the page allocator.  This has been true but only for allocations
    requests larger than PAGE_ALLOC_COSTLY_ORDER.  It has been always
    ignored for smaller sizes.  This is a bit unfortunate because there is
    no way to express the same semantic for those requests and they are
    considered too important to fail so they might end up looping in the
    page allocator for ever, similarly to GFP_NOFAIL requests.
    
    Now that the whole tree has been cleaned up and accidental or misled
    usage of __GFP_REPEAT flag has been removed for !costly requests we can
    give the original flag a better name and more importantly a more useful
    semantic.  Let's rename it to __GFP_RETRY_MAYFAIL which tells the user
    that the allocator would try really hard but there is no promise of a
    success.  This will work independent of the order and overrides the
    default allocator behavior.  Page allocator users have several levels of
    guarantee vs.  cost options (take GFP_KERNEL as an example)
    
     - GFP_KERNEL & ~__GFP_RECLAIM - optimistic allocation without _any_
       attempt to free memory at all. The most light weight mode which even
       doesn't kick the background reclaim. Should be used carefully because
       it might deplete the memory and the next user might hit the more
       aggressive reclaim
    
     - GFP_KERNEL & ~__GFP_DIRECT_RECLAIM (or GFP_NOWAIT)- optimistic
       allocation without any attempt to free memory from the current
       context but can wake kswapd to reclaim memory if the zone is below
       the low watermark. Can be used from either atomic contexts or when
       the request is a performance optimization and there is another
       fallback for a slow path.
    
     - (GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM (aka GFP_ATOMIC) -
       non sleeping allocation with an expensive fallback so it can access
       some portion of memory reserves. Usually used from interrupt/bh
       context with an expensive slow path fallback.
    
     - GFP_KERNEL - both background and direct reclaim are allowed and the
       _default_ page allocator behavior is used. That means that !costly
       allocation requests are basically nofail but there is no guarantee of
       that behavior so failures have to be checked properly by callers
       (e.g. OOM killer victim is allowed to fail currently).
    
     - GFP_KERNEL | __GFP_NORETRY - overrides the default allocator behavior
       and all allocation requests fail early rather than cause disruptive
       reclaim (one round of reclaim in this implementation). The OOM killer
       is not invoked.
    
     - GFP_KERNEL | __GFP_RETRY_MAYFAIL - overrides the default allocator
       behavior and all allocation requests try really hard. The request
       will fail if the reclaim cannot make any progress. The OOM killer
       won't be triggered.
    
     - GFP_KERNEL | __GFP_NOFAIL - overrides the default allocator behavior
       and all allocation requests will loop endlessly until they succeed.
       This might be really dangerous especially for larger orders.
    
    Existing users of __GFP_REPEAT are changed to __GFP_RETRY_MAYFAIL
    because they already had their semantic.  No new users are added.
    __alloc_pages_slowpath is changed to bail out for __GFP_RETRY_MAYFAIL if
    there is no progress and we have already passed the OOM point.
    
    This means that all the reclaim opportunities have been exhausted except
    the most disruptive one (the OOM killer) and a user defined fallback
    behavior is more sensible than keep retrying in the page allocator.
    
    [akpm@linux-foundation.org: fix arch/sparc/kernel/mdesc.c]
    [mhocko@suse.com: semantic fix]
      Link: http://lkml.kernel.org/r/20170626123847.GM11534@dhcp22.suse.cz
    [mhocko@kernel.org: address other thing spotted by Vlastimil]
      Link: http://lkml.kernel.org/r/20170626124233.GN11534@dhcp22.suse.cz
    Link: http://lkml.kernel.org/r/20170623085345.11304-3-mhocko@kernel.org
    
    
    Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
    Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
    Cc: Alex Belits <alex.belits@cavium.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Darrick J. Wong <darrick.wong@oracle.com>
    Cc: David Daney <david.daney@cavium.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: NeilBrown <neilb@suse.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    dcda9b04