lkml.org 
[lkml]   [2017]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag
    Hi!

    > From: Michal Hocko <mhocko@suse.com>
    >
    > GFP_TEMPORARY has been introduced by e12ba74d8ff3 ("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.

    Dunno. < 1msec probably is temporary, 1 hour probably is not. If it causes
    problems, can you just #define GFP_TEMPORARY GFP_KERNEL ? Treewide replace,
    and then starting again goes not look attractive to me.

    Pavel

    \
     
     \ /
      Last update: 2017-08-24 18:03    [W:3.061 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site