diff options
author | Michal Hocko <mhocko@suse.com> | 2017-08-24 09:44:46 +1000 |
---|---|---|
committer | Stephen Rothwell <sfr@canb.auug.org.au> | 2017-08-25 18:09:15 +1000 |
commit | a1b7db5642aafae786b0cfc263fe1583b2841f4a (patch) | |
tree | 071b191c9108bced12b9c69a9a9948a308a3eace /drivers/gpu/drm/msm | |
parent | ae8c62a0fea5e5f679c48077272a553d67f806f0 (diff) | |
download | linux-next-a1b7db5642aafae786b0cfc263fe1583b2841f4a.tar.gz |
mm: treewide: remove GFP_TEMPORARY allocation flag
GFP_TEMPORARY was 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.
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
Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Acked-by: Vlastimil 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Diffstat (limited to 'drivers/gpu/drm/msm')
-rw-r--r-- | drivers/gpu/drm/msm/msm_gem_submit.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index debe79cf080b..56ce4c442ef5 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -41,7 +41,7 @@ static struct msm_gem_submit *submit_create(struct drm_device *dev, if (sz > SIZE_MAX) return NULL; - submit = kmalloc(sz, GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY); + submit = kmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY); if (!submit) return NULL; |