lkml.org 
[lkml]   [2015]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 06/10] mm, page_alloc: Rename __GFP_WAIT to __GFP_RECLAIM
From
Date
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?



\
 
 \ /
  Last update: 2015-10-01 11:01    [W:0.094 / U:24.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site