lkml.org 
[lkml]   [2015]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 06/10] mm, page_alloc: Rename __GFP_WAIT to __GFP_RECLAIM
On Mon, 21 Sep 2015 11:52:38 +0100 Mel Gorman <mgorman@techsingularity.net> wrote:

> __GFP_WAIT was used to signal that the caller was in atomic context and
> could not sleep. Now it is possible to distinguish between true atomic
> context and callers that are not willing to sleep. The latter should clear
> __GFP_DIRECT_RECLAIM so kswapd will still wake. As clearing __GFP_WAIT
> behaves differently, there is a risk that people will clear the wrong
> flags. This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly indicate
> what it does -- setting it allows all reclaim activity, clearing them
> prevents it.

We have quite a history of remote parts of the kernel using
weird/wrong/inexplicable combinations of __GFP_ flags. I tend to think
that this is because we didn't adequately explain the interface.

And I don't think that gfp.h really improved much in this area as a
result of this patchset. Could you go through it some time and decide
if we've adequately documented all this stuff?

GFP_ATOMIC vs GFP_NOWAIT?

GFP_USER vs GFP_HIGHUSER?

When should I use GFP_HIGHUSER_MOVABLE instead?

Why isn't there a GFP_USER_MOVABLE?

What's GFP_IOFS?

GFP_RECLAIM_MASK through GFP_SLAB_BUG_MASK are mm-internal, but look
the same as the exported interface definitions.

__GFP_MOVABLE is documented twice, the second in an odd place.

etcetera.


It's rather unclear which symbols are part of the exported interface
and which are "mm internal only".


\
 
 \ /
  Last update: 2015-09-29 02:21    [W:0.218 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site