From: Yafang Shao <laoar.shao@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Roman Gushchin <guro@fb.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
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>,
Souptick Joarder <jrdr.linux@gmail.com>,
Yafang Shao <shaoyafang@didiglobal.com>
Subject: Re: [PATCH v2] mm, memcg: skip killing processes under memcg protection at first scan
Date: Wed, 21 Aug 2019 15:26:56 +0800 [thread overview]
Message-ID: <CALOAHbAt6nm+qSOLGTeo5s5XjQFcasQw9HJfKEEC24xVOoVxwg@mail.gmail.com> (raw)
In-Reply-To: <20190821064452.GV3111@dhcp22.suse.cz>
On Wed, Aug 21, 2019 at 2:44 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Wed 21-08-19 09:00:39, Yafang Shao wrote:
> [...]
> > More possible OOMs is also a strong side effect (and it prevent us
> > from using it).
>
> So why don't you use low limit if the guarantee side of min limit is too
> strong for you?
Well, I don't know what the best-practice of memory.min is.
In our plan, we want to use it to protect the top priority containers
(e.g. set the memory.min same with memory limit), which may latency
sensive. Using memory.min may sometimes decrease the refault.
If we set it too low, it may useless, becasue what memory.min is
protecting is not specified. And if there're some busrt anon memory
allocate in this memcg, the memory.min may can't protect any file
memory.
I appreciate if you could show me some best practice of it.
Thanks
Yafang
next prev parent reply other threads:[~2019-08-21 7:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 1:18 Yafang Shao
2019-08-19 21:12 ` Roman Gushchin
2019-08-20 1:16 ` Yafang Shao
2019-08-20 1:39 ` Roman Gushchin
2019-08-20 2:01 ` Yafang Shao
2019-08-20 2:40 ` Yafang Shao
2019-08-20 6:40 ` Michal Hocko
2019-08-20 7:15 ` Yafang Shao
2019-08-20 7:27 ` Michal Hocko
2019-08-20 7:49 ` Yafang Shao
2019-08-20 8:34 ` Michal Hocko
2019-08-20 8:55 ` Yafang Shao
2019-08-20 9:17 ` Michal Hocko
2019-08-20 9:26 ` Yafang Shao
2019-08-20 10:40 ` Michal Hocko
2019-08-20 21:39 ` Roman Gushchin
2019-08-21 1:00 ` Yafang Shao
2019-08-21 6:44 ` Michal Hocko
2019-08-21 7:26 ` Yafang Shao [this message]
2019-08-21 8:05 ` Michal Hocko
2019-08-21 8:15 ` Yafang Shao
2019-08-21 8:34 ` Michal Hocko
2019-08-21 8:46 ` 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=CALOAHbAt6nm+qSOLGTeo5s5XjQFcasQw9HJfKEEC24xVOoVxwg@mail.gmail.com \
--to=laoar.shao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=jrdr.linux@gmail.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rdunlap@infradead.org \
--cc=shaoyafang@didiglobal.com \
--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