From: Hillf Danton <hdanton@sina.com>
To: Roman Gushchin <guro@fb.com>, Michal Hocko <mhocko@kernel.org>
Cc: Hillf Danton <hdanton@sina.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>, Shakeel Butt <shakeelb@google.com>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [RFC] mm: memcg: add priority for soft limit reclaiming
Date: Wed, 25 Sep 2019 10:35:30 +0800 [thread overview]
Message-ID: <20190925023530.6364-1-hdanton@sina.com> (raw)
In-Reply-To: <20190924133016.GT23050@dhcp22.suse.cz>
On Tue, 24 Sep 2019 17:23:35 +0000 from Roman Gushchin
>
> On Tue, Sep 24, 2019 at 03:30:16PM +0200, Michal Hocko wrote:
> >
> > But really, make sure you look into the existing feature set that memcg
> > v2 provides already and come back if you find it unsuitable and we can
> > move from there. Soft limit reclaim is dead and we should let it RIP.
>
> Can't agree more here.
>
> Cgroup v2 memory protection mechanisms (memory.low/min) should perfectly
> solve the described problem. If not, let's fix them rather than extend soft
> reclaim which is already dead.
>
Hehe, IIUC memory.low/min is essentially drawing a line that reclaimers
would try their best not to cross. Page preemption OTOH is near ten miles
away from that line though it is now on the shoulder of soft reclaiming.
next prev parent reply other threads:[~2019-09-25 2:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-24 7:36 [RFC] mm: memcg: add priority for soft limit reclaiming Hillf Danton
2019-09-24 13:30 ` Michal Hocko
2019-09-24 17:23 ` Roman Gushchin
2019-09-25 2:35 ` Hillf Danton [this message]
2019-09-25 6:52 ` Michal Hocko
-- strict thread matches above, loose matches on Subject: below --
2019-09-19 13:13 Hillf Danton
2019-09-19 13:32 ` Michal Hocko
2019-09-23 13:04 ` Hillf Danton
2019-09-23 13:28 ` Michal Hocko
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=20190925023530.6364-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=shakeelb@google.com \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).