Messages in this thread | | | Date | Mon, 28 Sep 2015 16:55:23 -0700 | From | Andrew Morton <> | Subject | Re: [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".
| |