Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag

From: Michal Hocko
Date: Fri Jul 28 2017 - 06:27:50 EST


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 <mhocko@xxxxxxxx>
> >
> > 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 <mgorman@xxxxxxx>

Thanks!
--
Michal Hocko
SUSE Labs