From: Johannes Weiner <hannes@cmpxchg.org>
To: Roman Gushchin <guro@fb.com>
Cc: Shakeel Butt <shakeelb@google.com>,
Michal Hocko <mhocko@kernel.org>,
Greg Thelen <gthelen@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max
Date: Thu, 30 Apr 2020 15:30:49 -0400 [thread overview]
Message-ID: <20200430193049.GB2436@cmpxchg.org> (raw)
In-Reply-To: <20200430190610.GD339283@carbon.dhcp.thefacebook.com>
On Thu, Apr 30, 2020 at 12:06:10PM -0700, Roman Gushchin wrote:
> On Thu, Apr 30, 2020 at 11:27:12AM -0700, Shakeel Butt wrote:
> > @@ -6106,7 +6107,7 @@ static ssize_t memory_max_write(struct kernfs_open_file *of,
> > }
> >
> > memcg_memory_event(memcg, MEMCG_OOM);
> > - if (!mem_cgroup_out_of_memory(memcg, GFP_KERNEL, 0))
> > + if (!mem_cgroup_out_of_memory(memcg, GFP_KERNEL, 0, true))
>
> I wonder if we can handle it automatically from the oom_killer side?
> We can suppress warnings if oc->memcg is set and the cgroup scanning
> showed that there are no belonging processes?
Note that we do remote charging for certain consumers, where memory
gets charged from the outside of the cgroup.
We would want to know if these cause OOMs on an empty cgroup, rather
than force-charge the allocations quietly.
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
To: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
Cc: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max
Date: Thu, 30 Apr 2020 15:30:49 -0400 [thread overview]
Message-ID: <20200430193049.GB2436@cmpxchg.org> (raw)
In-Reply-To: <20200430190610.GD339283-cx5fftMpWqeCjSd+JxjunQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
On Thu, Apr 30, 2020 at 12:06:10PM -0700, Roman Gushchin wrote:
> On Thu, Apr 30, 2020 at 11:27:12AM -0700, Shakeel Butt wrote:
> > @@ -6106,7 +6107,7 @@ static ssize_t memory_max_write(struct kernfs_open_file *of,
> > }
> >
> > memcg_memory_event(memcg, MEMCG_OOM);
> > - if (!mem_cgroup_out_of_memory(memcg, GFP_KERNEL, 0))
> > + if (!mem_cgroup_out_of_memory(memcg, GFP_KERNEL, 0, true))
>
> I wonder if we can handle it automatically from the oom_killer side?
> We can suppress warnings if oc->memcg is set and the cgroup scanning
> showed that there are no belonging processes?
Note that we do remote charging for certain consumers, where memory
gets charged from the outside of the cgroup.
We would want to know if these cause OOMs on an empty cgroup, rather
than force-charge the allocations quietly.
next prev parent reply other threads:[~2020-04-30 19:31 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 [this message]
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
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=20200430193049.GB2436@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=gthelen@google.com \
--cc=guro@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.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: link
Be 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.