• Michal Hocko's avatar
    mm: treewide: remove GFP_TEMPORARY allocation flag · 0ee931c4
    Michal Hocko authored
    GFP_TEMPORARY was introduced by commit e12ba74d ("Group short-lived
    and reclaimable kernel allocations") along with __GFP_RECLAIMABLE.  It's
    primary motivation was to allow users to tell that an allocation is
    short lived and so the allocator can try to place such allocations close
    together and prevent long term fragmentation.  As much as this sounds
    like a reasonable semantic it becomes much less clear when to use the
    highlevel GFP_TEMPORARY allocation flag.  How long is temporary? Can the
    context holding that memory sleep? Can it take locks? It seems there is
    no good answer for those questions.
    
    The current implementation of GFP_TEMPORARY is basically GFP_KERNEL |
    __GFP_RECLAIMABLE which in itself is tricky because basically none of
    the existing caller provide a way to reclaim the allocated memory.  So
    this is rather misleading and hard to evaluate for any benefits.
    
    I have checked some random users and none of them has added the flag
    with a specific justification.  I suspect most of them just copied from
    other existing users and others just thought it might be a good idea to
    use without any measuring.  This suggests that GFP_TEMPORARY just
    motivates for cargo cult usage without any reasoning.
    
    I believe that our gfp flags are quite complex already and especially
    those with highlevel semantic should be clearly defined to prevent from
    confusion and abuse.  Therefore I propose dropping GFP_TEMPORARY and
    replace all existing users to simply use GFP_KERNEL.  Please note that
    SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and
    so they will be placed properly for memory fragmentation prevention.
    
    I can see reasons we might want some gfp flag to reflect shorterm
    allocations but I propose starting from a clear semantic definition and
    only then add users with proper justification.
    
    This was been brought up before LSF this year by Matthew [1] and it
    turned out that GFP_TEMPORARY really doesn't have a clear semantic.  It
    seems to be a heuristic without any measured advantage for most (if not
    all) its current users.  The follow up discussion has revealed that
    opinions on what might be temporary allocation differ a lot between
    developers.  So rather than trying to tweak existing users into a
    semantic which they haven't expected I propose to simply remove the flag
    and start from scratch if we really need a semantic for short term
    allocations.
    
    [1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org
    
    [akpm@linux-foundation.org: fix typo]
    [akpm@linux-foundation.org: coding-style fixes]
    [sfr@canb.auug.org.au: drm/i915: fix up]
      Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au
    Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
    Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
    Acked-by: default avatarMel Gorman <mgorman@suse.de>
    Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Neil Brown <neilb@suse.de>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    0ee931c4
suspend.c 6.63 KB