linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Yafang Shao <laoar.shao@gmail.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 08:31:20 +0200	[thread overview]
Message-ID: <20190820063120.GD3111@dhcp22.suse.cz> (raw)
In-Reply-To: <CALOAHbAo2MLkavFZz_5f5hvXE8BzYW8R-yjw5acnwT315TxoMQ@mail.gmail.com>

[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.

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?
 
> 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.

> Is this setting proper ?
> 
> Thanks
> Yafang

-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2019-08-20  6:31 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 [this message]
2019-08-20  7:02       ` Yafang Shao

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=20190820063120.GD3111@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-mm@kvack.org \
    --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