lkml.org 
[lkml]   [2017]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2/6] mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic
    From
    Date
    On 06/23/2017 10:53 AM, Michal Hocko wrote:
    > From: Michal Hocko <mhocko@suse.com>
    >
    > __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 (unless the requesting task
    > is killed by the OOM killer)

    Should we explicitly point out that failure must be handled? After lots
    of talking about "too small to fail", people might get the wrong impression.

    > and costly will fail early rather than
    > cause disruptive reclaim.
    > - 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.
    >
    > Changes since RFC
    > - udpate documentation wording as per Neil Brown
    >
    > Signed-off-by: Michal Hocko <mhocko@suse.com>

    Acked-by: Vlastimil Babka <vbabka@suse.cz>

    Some more minor comments below:

    ...

    > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
    > index 4c6656f1fee7..6be1f836b69e 100644
    > --- a/include/linux/gfp.h
    > +++ b/include/linux/gfp.h
    > @@ -25,7 +25,7 @@ struct vm_area_struct;
    > #define ___GFP_FS 0x80u
    > #define ___GFP_COLD 0x100u
    > #define ___GFP_NOWARN 0x200u
    > -#define ___GFP_REPEAT 0x400u
    > +#define ___GFP_RETRY_MAYFAIL 0x400u

    Seems like one tab too many, the end result is off:
    (sigh, tabs are not only error prone, but also we make less money due to
    them, I heard)

    #define ___GFP_NOWARN 0x200u
    #define ___GFP_RETRY_MAYFAIL 0x400u
    #define ___GFP_NOFAIL 0x800u


    > #define ___GFP_NOFAIL 0x800u
    > #define ___GFP_NORETRY 0x1000u
    > #define ___GFP_MEMALLOC 0x2000u
    > @@ -136,26 +136,55 @@ struct vm_area_struct;
    > *
    > * __GFP_RECLAIM is shorthand to allow/forbid both direct and kswapd reclaim.
    > *
    > - * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
    > - * _might_ fail. This depends upon the particular VM implementation.
    > + * The default allocator behavior depends on the request size. We have a concept
    > + * of so called costly allocations (with order > PAGE_ALLOC_COSTLY_ORDER).
    > + * !costly allocations are too essential to fail so they are implicitly
    > + * non-failing (with some exceptions like OOM victims might fail) by default while

    Again, emphasize need for error handling?

    \
     
     \ /
      Last update: 2017-06-26 13:46    [W:2.249 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site