Dan Schatzberg writes:
Our container agent wants to know when a container exits if it was OOM killed or not to report to the user. We use memory.oom.group = 1 to ensure that OOM kills within the container's cgroup kill everything. Existing memory.events are insufficient for knowing if this triggered: 1) Our current approach reads memory.events oom_kill and reports the container was killed if the value is non-zero. This is erroneous in some cases where containers create their children cgroups with memory.oom.group=1 as such OOM kills will get counted against the container cgroup's oom_kill counter despite not actually OOM killing the entire container. 2) Reading memory.events.local will fail to identify OOM kills in leaf cgroups (that don't set memory.oom.group) within the container cgroup. This patch adds a new oom_group_kill event when memory.oom.group triggers to allow userspace to cleanly identify when an entire cgroup is oom killed. Signed-off-by: Dan Schatzberg <schatzberg.dan@xxxxxxxxx>
Thanks! Acking with one minor point on the documentation front. Acked-by: Chris Down <chris@xxxxxxxxxxxxxx>
--- Documentation/admin-guide/cgroup-v2.rst | 4 ++++ include/linux/memcontrol.h | 1 + mm/memcontrol.c | 5 +++++ mm/oom_kill.c | 1 + 4 files changed, 11 insertions(+) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 2aeb7ae8b393..eec830ce2068 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1268,6 +1268,10 @@ PAGE_SIZE multiple when read back. The number of processes belonging to this cgroup killed by any kind of OOM killer. + oom_group_kill + The number of times all tasks in the cgroup were killed + due to memory.oom.group.
Maybe pedantic, but this reads as unclear to me whether in cgroup with 3 tasks we get the value "3" or "1" when a group kill occurs.
Maybe rephrase to not make be about tasks and just say "number of times a group OOM occurred"?
