Messages in this thread | | | Subject | Re: [PATCH 06/10] mm, page_alloc: Rename __GFP_WAIT to __GFP_RECLAIM | From | Vlastimil Babka <> | Date | Thu, 1 Oct 2015 10:39:16 +0200 |
| |
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?
| |