|author||Konstantin Khlebnikov <email@example.com>||2020-05-30 14:51:17 +1000|
|committer||Stephen Rothwell <firstname.lastname@example.org>||2020-06-02 19:28:40 +1000|
doc: cgroup: update note about conditions when oom killer is invoked
Starting from v4.19 commit 29ef680ae7c2 ("memcg, oom: move out_of_memory back to the charge path") cgroup oom killer is no longer invoked only from page faults. Now it implements the same semantics as global OOM killer: allocation context invokes OOM killer and keeps retrying until success. Link: http://lkml.kernel.org/r/158894738928.208854.5244393925922074518.stgit@buzz Signed-off-by: Konstantin Khlebnikov <email@example.com> Acked-by: Michal Hocko <firstname.lastname@example.org> Cc: Roman Gushchin <email@example.com> Cc: Randy Dunlap <firstname.lastname@example.org> Signed-off-by: Andrew Morton <email@example.com> Signed-off-by: Stephen Rothwell <firstname.lastname@example.org>
1 files changed, 8 insertions, 9 deletions
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index c2a4b652bd1a..5f63f1ba0302 100644
@@ -1170,6 +1170,13 @@ PAGE_SIZE multiple when read back.
Under certain circumstances, the usage may go over the limit
+ In default configuration regular 0-order allocation always
+ succeed unless OOM killer choose current task as a victim.
+ Some kinds of allocations don't invoke the OOM killer.
+ Caller could retry them differently, return into userspace
+ as -ENOMEM or silently ignore in cases like disk readahead.
This is the ultimate protection mechanism. As long as the
high limit is used and monitored properly, this limit's
utility is limited to providing the final safety net.
@@ -1226,17 +1233,9 @@ PAGE_SIZE multiple when read back.
The number of time the cgroup's memory usage was
reached the limit and allocation was about to fail.
- Depending on context result could be invocation of OOM
- killer and retrying allocation or failing allocation.
- Failed allocation in its turn could be returned into
- userspace as -ENOMEM or silently ignored in cases like
- disk readahead. For now OOM in memory cgroup kills
- tasks iff shortage has happened inside page fault.
This event is not raised if the OOM killer is not
considered as an option, e.g. for failed high-order
+ allocations or if caller asked to not retry attempts.
The number of processes belonging to this cgroup