linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


      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