Commit 00bafa57 authored by Mike Rapoport's avatar Mike Rapoport Committed by Jonathan Corbet

docs/core-api: memory-allocation: describe reclaim behaviour

Changelog of commit dcda9b04 ("mm, tree wide: replace __GFP_REPEAT by
__GFP_RETRY_MAYFAIL with more useful semantic") has very nice description
of GFP flags that affect reclaim behaviour of the page allocator.

It would be pity to keep this description buried in the log so let's expose
it in the Documentation/ as well.

Cc: Michal Hocko <mhocko@suse.com>
Acked-by: default avatarMichal Hocko <mhocko@suse.com>
Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
Link: https://lore.kernel.org/r/20200719153641.231131-1-rppt@kernel.orgSigned-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent 2ed1761f
...@@ -84,6 +84,50 @@ driver for a device with such restrictions, avoid using these flags. ...@@ -84,6 +84,50 @@ driver for a device with such restrictions, avoid using these flags.
And even with hardware with restrictions it is preferable to use And even with hardware with restrictions it is preferable to use
`dma_alloc*` APIs. `dma_alloc*` APIs.
GFP flags and reclaim behavior
------------------------------
Memory allocations may trigger direct or background reclaim and it is
useful to understand how hard the page allocator will try to satisfy that
or another request.
* ``GFP_KERNEL & ~__GFP_RECLAIM`` - optimistic allocation without _any_
attempt to free memory at all. The most light weight mode which even
doesn't kick the background reclaim. Should be used carefully because it
might deplete the memory and the next user might hit the more aggressive
reclaim.
* ``GFP_KERNEL & ~__GFP_DIRECT_RECLAIM`` (or ``GFP_NOWAIT``)- optimistic
allocation without any attempt to free memory from the current
context but can wake kswapd to reclaim memory if the zone is below
the low watermark. Can be used from either atomic contexts or when
the request is a performance optimization and there is another
fallback for a slow path.
* ``(GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM`` (aka ``GFP_ATOMIC``) -
non sleeping allocation with an expensive fallback so it can access
some portion of memory reserves. Usually used from interrupt/bottom-half
context with an expensive slow path fallback.
* ``GFP_KERNEL`` - both background and direct reclaim are allowed and the
**default** page allocator behavior is used. That means that not costly
allocation requests are basically no-fail but there is no guarantee of
that behavior so failures have to be checked properly by callers
(e.g. OOM killer victim is allowed to fail currently).
* ``GFP_KERNEL | __GFP_NORETRY`` - overrides the default allocator behavior
and all allocation requests fail early rather than cause disruptive
reclaim (one round of reclaim in this implementation). The OOM killer
is not invoked.
* ``GFP_KERNEL | __GFP_RETRY_MAYFAIL`` - overrides the default allocator
behavior and all allocation requests try really hard. The request
will fail if the reclaim cannot make any progress. The OOM killer
won't be triggered.
* ``GFP_KERNEL | __GFP_NOFAIL`` - overrides the default allocator behavior
and all allocation requests will loop endlessly until they succeed.
This might be really dangerous especially for larger orders.
Selecting memory allocator Selecting memory allocator
========================== ==========================
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment