[lkml]   [2017]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag
On Fri 28-07-17 10:52:49, Mel Gorman wrote:
> On Fri, Jul 28, 2017 at 11:19:04AM +0200, Michal Hocko wrote:
> > From: Michal Hocko <>
> >
> > 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.
> >
> At the time of the introduction, the users were all very short-lived
> where short was for operations such as reading a proc file that discarded
> buffers afterwards.

Maybe we can add a special slab cache for those?

> However, it does seem to have misused over the last
> few years and it was too easy to confuse "temporary" with "short lived"
> and too easy to get confused about "how short lived is short lived?". On
> that basis;
> Acked-by: Mel Gorman <>

Michal Hocko

 \ /
  Last update: 2017-07-28 12:28    [W:0.098 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site