| Message ID | 20211203162426.3375036-1-schatzberg.dan@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: add group_oom_kill memory event | expand |
On Fri, Dec 03, 2021 at 08:24:23AM -0800, Dan Schatzberg wrote: > 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@gmail.com> Reviewed-by: Roman Gushchin <guro@fb.com> Thanks!
On Fri, Dec 3, 2021 at 8:24 AM Dan Schatzberg <schatzberg.dan@gmail.com> wrote: > > 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@gmail.com> So, with this patch, will you be watching oom_group_kill from memory.events or memory.events.local file for your use-case? Reviewed-by: Shakeel Butt <shakeelb@google.com>
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@gmail.com> Thanks! Acking with one minor point on the documentation front. Acked-by: Chris Down <chris@chrisdown.name> >--- > 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"?
On Fri, Dec 03, 2021 at 04:45:54PM -0800, Shakeel Butt wrote: > On Fri, Dec 3, 2021 at 8:24 AM Dan Schatzberg <schatzberg.dan@gmail.com> wrote: > > > > 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@gmail.com> > > So, with this patch, will you be watching oom_group_kill from > memory.events or memory.events.local file for your use-case? > > Reviewed-by: Shakeel Butt <shakeelb@google.com> We will watch from memory.events.local. If containers want to construct their own child cgroups and allow for group oom to occur inside, that's fine - a future container exit should not result in us claiming the container was OOM killed. If the container exits and memory.event.local shows oom_group_kill > 0 then we know the container was OOM killed.
On Fri 03-12-21 08:24:23, Dan Schatzberg wrote: > 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: Yes our events reporting is not really friendly for this kind of usage. OOM_KILL is accounted to the memcg of the task so it will not be updated for inter nodes other than recursively (so never in local events). OOM event, even though it is reported to the memcg under oom, cannot be really used either because in some cases the oom killer is simply not invoked. So there indeed is no clear way to tell what is happening under the memcg hierarchy and what is happening for the whole hierarchy. > 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. I am a bit confused by 2). local events by definition cannot tell you anything about children cgroups. > 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. New counter makes sense to me because it allows to tell oom events even on the middle nodes. > Signed-off-by: Dan Schatzberg <schatzberg.dan@gmail.com> once the cgroup v1 interface part is dropped (as suggested by Johannes), feel free to add Acked-by: Michal Hocko <mhocko@suse.com> > --- > 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. This can be rather confusing for hierarchicaly reported values but the same applies for other counters as well. So be it. [...] > @@ -4390,6 +4390,9 @@ static int mem_cgroup_oom_control_read(struct seq_file *sf, void *v) > seq_printf(sf, "under_oom %d\n", (bool)memcg->under_oom); > seq_printf(sf, "oom_kill %lu\n", > atomic_long_read(&memcg->memory_events[MEMCG_OOM_KILL])); > + seq_printf(sf, "oom_group_kill %lu\n", > + atomic_long_read( > + &memcg->memory_events[MEMCG_OOM_GROUP_KILL])); > return 0; > } This should be dropped.
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. + memory.events.local Similar to memory.events but the fields in the file are local to the cgroup i.e. not hierarchical. The file modified event diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 0c5c403f4be6..951f24f42147 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -42,6 +42,7 @@ enum memcg_memory_event { MEMCG_MAX, MEMCG_OOM, MEMCG_OOM_KILL, + MEMCG_OOM_GROUP_KILL, MEMCG_SWAP_HIGH, MEMCG_SWAP_MAX, MEMCG_SWAP_FAIL, diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 6863a834ed42..5ab3b9ce90de 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -4390,6 +4390,9 @@ static int mem_cgroup_oom_control_read(struct seq_file *sf, void *v) seq_printf(sf, "under_oom %d\n", (bool)memcg->under_oom); seq_printf(sf, "oom_kill %lu\n", atomic_long_read(&memcg->memory_events[MEMCG_OOM_KILL])); + seq_printf(sf, "oom_group_kill %lu\n", + atomic_long_read( + &memcg->memory_events[MEMCG_OOM_GROUP_KILL])); return 0; } @@ -6307,6 +6310,8 @@ static void __memory_events_show(struct seq_file *m, atomic_long_t *events) seq_printf(m, "oom %lu\n", atomic_long_read(&events[MEMCG_OOM])); seq_printf(m, "oom_kill %lu\n", atomic_long_read(&events[MEMCG_OOM_KILL])); + seq_printf(m, "oom_group_kill %lu\n", + atomic_long_read(&events[MEMCG_OOM_GROUP_KILL])); } static int memory_events_show(struct seq_file *m, void *v) diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 1ddabefcfb5a..e52ce0b1465d 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -994,6 +994,7 @@ static void oom_kill_process(struct oom_control *oc, const char *message) * If necessary, kill all tasks in the selected memory cgroup. */ if (oom_group) { + memcg_memory_event(oom_group, MEMCG_OOM_GROUP_KILL); mem_cgroup_print_oom_group(oom_group); mem_cgroup_scan_tasks(oom_group, oom_kill_memcg_member, (void *)message);
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@gmail.com> --- 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(+)