From: Yafang Shao <laoar.shao@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux MM <linux-mm@kvack.org>, Roman Gushchin <guro@fb.com>,
Randy Dunlap <rdunlap@infradead.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Subject: Re: [PATCH] mm, memcg: skip killing processes under memcg protection at first scan
Date: Tue, 20 Aug 2019 15:02:13 +0800 [thread overview]
Message-ID: <CALOAHbCwqWeZ4JdXpOMm-y2UdZafrU6-efbuE4iiPEC8-7ncUg@mail.gmail.com> (raw)
In-Reply-To: <20190820063120.GD3111@dhcp22.suse.cz>
On Tue, Aug 20, 2019 at 2:31 PM Michal Hocko <mhocko@suse.com> wrote:
>
> [hmm the email got stuck on my send queue - sending again]
>
> On Mon 19-08-19 16:15:08, Yafang Shao wrote:
> > On Mon, Aug 19, 2019 at 3:31 PM Michal Hocko <mhocko@suse.com> wrote:
> > >
> > > On Sun 18-08-19 00:24:54, Yafang Shao wrote:
> > > > In the current memory.min design, the system is going to do OOM instead
> > > > of reclaiming the reclaimable pages protected by memory.min if the
> > > > system is lack of free memory. While under this condition, the OOM
> > > > killer may kill the processes in the memcg protected by memory.min.
> > >
> > > Could you be more specific about the configuration that leads to this
> > > situation?
> >
> > When I did memory pressure test to verify memory.min I found that issue.
> > This issue can be produced as bellow,
> > memcg setting,
> > memory.max: 1G
> > memory.min: 512M
> > some processes are running is this memcg, with both serveral
> > hundreds MB file mapping and serveral hundreds MB anon mapping.
> > system setting,
> > swap: off.
> > some memory pressure test are running on the system.
> >
> > When the memory usage of this memcg is bellow the memory.min, the
> > global reclaimers stop reclaiming pages in this memcg, and when
> > there's no available memory, the OOM killer will be invoked.
> > Unfortunately the OOM killer can chose the process running in the
> > protected memcg.
>
> Well, the memcg protection was designed to prevent from regular
> memory reclaim. It was not aimed at acting as a group wide oom
> protection. The global oom killer (but memcg as well) simply cares only
> about oom_score_adj when selecting a victim.
>
OOM is a kind of memory reclaim, isn't it ?
> Adding yet another oom protection is likely to complicate the oom
> selection logic and make it more surprising. E.g. why should workload
> fitting inside the min limit be so special? Do you have any real world
> example?
>
The problem here is we want to use it ini the real world, but the
issuses we found prevent us from using it in the real world.
> > In order to produce it easy, you can incease the memroy.min and set
> > -1000 to the oom_socre_adj of the processes outside of the protected
> > memcg.
>
> This sounds like a very dubious configuration to me. There is no other
> option than chosing from the protected group.
>
This is only an easy example to produce it.
> > Is this setting proper ?
> >
> > Thanks
> > Yafang
>
> --
> Michal Hocko
> SUSE Labs
prev parent reply other threads:[~2019-08-20 7:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-18 4:24 Yafang Shao
2019-08-18 14:08 ` kbuild test robot
2019-08-18 14:08 ` kbuild test robot
2019-08-18 17:11 ` Souptick Joarder
2019-08-19 1:03 ` Yafang Shao
2019-08-19 7:31 ` Michal Hocko
2019-08-19 8:15 ` Yafang Shao
2019-08-20 6:31 ` Michal Hocko
2019-08-20 7:02 ` Yafang Shao [this message]
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=CALOAHbCwqWeZ4JdXpOMm-y2UdZafrU6-efbuE4iiPEC8-7ncUg@mail.gmail.com \
--to=laoar.shao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rdunlap@infradead.org \
--cc=vdavydov.dev@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox