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

[Vlastimil Babka <vbabka@suse.cz>]

On 09/29/2015 03:37 PM, Mel Gorman wrote:
> mm: page_alloc: Hide some GFP internals and document the bits and flag combinations
>
> Andrew started the following
>
> 	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?
>
> This patches first moves some GFP flag combinations that are part of the MM
> internals to mm/internal.h. The rest of the patch documents the __GFP_FOO
> bits under various headings and then documents the flag combinations. It
> will not help callers that are brain damaged but the clarity might motivate
> some fixes and avoid future mistakes.
>
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>

Acked-by: Vlastimil Babka <vbabka@suse.cz>

With some nitpicks below.

> +/*
> + * Reclaim modifiers
> + *
> + * __GFP_IO can start physical IO.
> + *
> + * __GFP_FS can call down to the low-level FS. Avoids the allocator

"Clearing the flag avoids..."? Avoids confusion.

> + *   recursing into the filesystem which might already be holding locks.
> + *
> + * __GFP_DIRECT_RECLAIM indicates that the caller may enter direct reclaim.
> + *   This flag can be cleared to avoid unnecessary delays when a fallback
> + *   option is available.
> + *
> + * __GFP_KSWAPD_RECLAIM indicates that the caller wants kswapd when the low

s/wants/wakes/? or "wants kswapd woken up"?

> + * GFP_USER is for userspace allocations that also need to be directly
> + *   accessibly by the kernel or hardware. It is typically used by hardware
> + *   for buffers that are mapped to userspace (e.g. graphics) that hardware
> + *   still must DMA to. cpuset limits are enforced for these allocations.
> + *
> + * GFP_HIGHUSER is for userspace allocations that may be mapped to userspace,
> + *   do not need to be directly accessible by the kernel but that cannot
> + *   move once in use. An example may be a hardware allocation that maps
> + *   data directly into userspace but has no addressing limitations.
> + *
> + * GFP_DMA exists for historical reasons and should be avoided where possible.
> + *   The flags indicates that the caller requires that the lowest zone be
> + *   used (ZONE_DMA or 16M on x86-64). Ideally, this would be removed but
> + *   it would require careful auditing as some users really require it and
> + *   others use the flag to avoid lowmem reserves in ZONE_DMA and treat the
> + *   lowest zone as a type of emergency reserve.
> + *
> + * GFP_DMA32 is similar to GFP_DMA except that the caller requires a 32-bit
> + *   address.
> + *
> + * GFP_HIGHUSER_MOVABLE is for userspace allocations that the kernel does not
> + *   need direct access to but can use kmap() when access is required. They
> + *   are expected to be movable via page reclaim or page migration. Typically,
> + *   pages on the LRU would also be allocated with GFP_HIGHUSER_MOVABLE.

Move GFP_HIGHUSER_MOVABLE right below GFP_HIGHUSER?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>