Re: [PATCH 06/10] mm, page_alloc: Rename __GFP_WAIT to __GFP_RECLAIM

From: Andrew Morton
Date: Mon Sep 28 2015 - 19:55:29 EST

On Mon, 21 Sep 2015 11:52:38 +0100 Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> 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?



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.


It's rather unclear which symbols are part of the exported interface
and which are "mm internal only".
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at