From: Michal Hocko <mhocko@kernel.org> To: Shakeel Butt <shakeelb@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org>, Roman Gushchin <guro@fb.com>, Greg Thelen <gthelen@google.com>, Andrew Morton <akpm@linux-foundation.org>, Linux MM <linux-mm@kvack.org>, Cgroups <cgroups@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max Date: Mon, 4 May 2020 18:06:13 +0200 [thread overview] Message-ID: <20200504160613.GU22838@dhcp22.suse.cz> (raw) In-Reply-To: <CALvZod7EeQm-T4dsBddfMY_szYw3m8gRh5R5GfjQiuQAtCocug@mail.gmail.com> On Mon 04-05-20 08:35:57, Shakeel Butt wrote: > On Mon, May 4, 2020 at 8:00 AM Michal Hocko <mhocko@kernel.org> wrote: > > > > On Mon 04-05-20 07:53:01, Shakeel Butt wrote: [...] > > > I am trying to see if "no eligible task" is really an issue and should > > > be warned for the "other use cases". The only real use-case I can > > > think of are resource managers adjusting the limit dynamically. I > > > don't see "no eligible task" a concerning reason for such use-case. > > > > It is very much a concerning reason to notify about like any other OOM > > situation due to hard limit breach. In this case it is worse in some > > sense because the limit cannot be trimmed down because there is no > > directly reclaimable memory at all. Such an oom situation is > > effectivelly conserved. > > -- > > Let me make a more precise statement and tell me if you agree. The "no > eligible task" is concerning for the charging path but not for the > writer of memory.max. The writer can read the usage and > cgroup.[procs|events] to figure out the situation if needed. I really hate to repeat myself but this is no different from a regular oom situation. Admin sets the hard limit and the kernel tries to act upon that. You cannot make any assumption about what admin wanted or didn't want to see. We simply trigger the oom killer on memory.max and this is a documented behavior. No eligible task or no task at all is a simply a corner case when the kernel cannot act and mentions that along with the oom report so that whoever consumes that information can debug or act on that fact. Silencing the oom report is simply removing a potentially useful aid to debug further a potential problem. But let me repeat this is not reallly any different from a regular oom situation when the oom killer is able to act. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>, Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Linux MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>, Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max Date: Mon, 4 May 2020 18:06:13 +0200 [thread overview] Message-ID: <20200504160613.GU22838@dhcp22.suse.cz> (raw) In-Reply-To: <CALvZod7EeQm-T4dsBddfMY_szYw3m8gRh5R5GfjQiuQAtCocug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Mon 04-05-20 08:35:57, Shakeel Butt wrote: > On Mon, May 4, 2020 at 8:00 AM Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > > > > On Mon 04-05-20 07:53:01, Shakeel Butt wrote: [...] > > > I am trying to see if "no eligible task" is really an issue and should > > > be warned for the "other use cases". The only real use-case I can > > > think of are resource managers adjusting the limit dynamically. I > > > don't see "no eligible task" a concerning reason for such use-case. > > > > It is very much a concerning reason to notify about like any other OOM > > situation due to hard limit breach. In this case it is worse in some > > sense because the limit cannot be trimmed down because there is no > > directly reclaimable memory at all. Such an oom situation is > > effectivelly conserved. > > -- > > Let me make a more precise statement and tell me if you agree. The "no > eligible task" is concerning for the charging path but not for the > writer of memory.max. The writer can read the usage and > cgroup.[procs|events] to figure out the situation if needed. I really hate to repeat myself but this is no different from a regular oom situation. Admin sets the hard limit and the kernel tries to act upon that. You cannot make any assumption about what admin wanted or didn't want to see. We simply trigger the oom killer on memory.max and this is a documented behavior. No eligible task or no task at all is a simply a corner case when the kernel cannot act and mentions that along with the oom report so that whoever consumes that information can debug or act on that fact. Silencing the oom report is simply removing a potentially useful aid to debug further a potential problem. But let me repeat this is not reallly any different from a regular oom situation when the oom killer is able to act. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2020-05-04 16:06 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-30 18:27 [PATCH] memcg: oom: ignore oom warnings from memory.max Shakeel Butt 2020-04-30 18:27 ` Shakeel Butt 2020-04-30 19:06 ` Roman Gushchin 2020-04-30 19:06 ` Roman Gushchin 2020-04-30 19:30 ` Johannes Weiner 2020-04-30 19:30 ` Johannes Weiner 2020-04-30 20:23 ` Roman Gushchin 2020-04-30 20:23 ` Roman Gushchin 2020-04-30 19:31 ` Shakeel Butt 2020-04-30 19:31 ` Shakeel Butt 2020-04-30 19:31 ` Shakeel Butt 2020-04-30 19:29 ` Johannes Weiner 2020-04-30 20:20 ` Shakeel Butt 2020-04-30 20:20 ` Shakeel Butt 2020-04-30 20:20 ` Shakeel Butt 2020-05-04 6:57 ` Michal Hocko 2020-05-04 6:57 ` Michal Hocko 2020-05-04 13:54 ` Shakeel Butt 2020-05-04 13:54 ` Shakeel Butt 2020-05-04 13:54 ` Shakeel Butt 2020-05-01 1:39 ` Yafang Shao 2020-05-01 1:39 ` Yafang Shao 2020-05-01 2:04 ` Shakeel Butt 2020-05-01 2:04 ` Shakeel Butt 2020-05-01 2:12 ` Yafang Shao 2020-05-01 2:12 ` Yafang Shao 2020-05-01 2:12 ` Yafang Shao 2020-05-04 7:03 ` Michal Hocko 2020-05-04 7:03 ` Michal Hocko 2020-05-04 7:26 ` Yafang Shao 2020-05-04 7:26 ` Yafang Shao 2020-05-04 7:26 ` Yafang Shao 2020-05-04 7:35 ` Michal Hocko 2020-05-04 7:40 ` Yafang Shao 2020-05-04 7:40 ` Yafang Shao 2020-05-04 7:40 ` Yafang Shao 2020-05-04 8:03 ` Michal Hocko 2020-05-04 8:03 ` Michal Hocko 2020-05-04 6:56 ` Michal Hocko 2020-05-04 6:56 ` Michal Hocko 2020-05-04 13:54 ` Shakeel Butt 2020-05-04 13:54 ` Shakeel Butt 2020-05-04 14:11 ` Michal Hocko 2020-05-04 14:53 ` Shakeel Butt 2020-05-04 14:53 ` Shakeel Butt 2020-05-04 14:53 ` Shakeel Butt 2020-05-04 15:00 ` Michal Hocko 2020-05-04 15:35 ` Shakeel Butt 2020-05-04 15:35 ` Shakeel Butt 2020-05-04 15:35 ` Shakeel Butt 2020-05-04 15:39 ` Yafang Shao 2020-05-04 15:39 ` Yafang Shao 2020-05-04 15:39 ` Yafang Shao 2020-05-04 16:06 ` Michal Hocko [this message] 2020-05-04 16:06 ` Michal Hocko 2020-05-04 19:23 ` Shakeel Butt 2020-05-04 19:23 ` Shakeel Butt 2020-05-05 7:13 ` Michal Hocko 2020-05-05 7:13 ` Michal Hocko 2020-05-05 15:03 ` Shakeel Butt 2020-05-05 15:03 ` Shakeel Butt 2020-05-05 16:57 ` Johannes Weiner 2020-05-05 16:57 ` Johannes Weiner 2020-05-05 15:27 ` Johannes Weiner 2020-05-05 15:27 ` Johannes Weiner 2020-05-05 15:35 ` Shakeel Butt 2020-05-05 15:35 ` Shakeel Butt 2020-05-05 15:35 ` Shakeel Butt 2020-05-05 15:49 ` Michal Hocko 2020-05-05 15:49 ` Michal Hocko 2020-05-05 16:40 ` Johannes Weiner 2020-05-05 16:40 ` Johannes Weiner 2020-05-04 14:20 ` Tetsuo Handa 2020-05-04 14:20 ` Tetsuo Handa 2020-05-04 14:57 ` Shakeel Butt 2020-05-04 14:57 ` Shakeel Butt 2020-05-04 15:44 ` Tetsuo Handa 2020-05-04 15:44 ` Tetsuo Handa
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200504160613.GU22838@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=gthelen@google.com \ --cc=guro@fb.com \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=shakeelb@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.