From: Michal Hocko <mhocko@kernel.org>
To: Hillf Danton <hdanton@sina.com>
Cc: Roman Gushchin <guro@fb.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 08:52:48 +0200 [thread overview]
Message-ID: <20190925065248.GF23050@dhcp22.suse.cz> (raw)
In-Reply-To: <20190925023530.6364-1-hdanton@sina.com>
On Wed 25-09-19 10:35:30, Hillf Danton wrote:
>
> 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.
Dynamic low limit tuning would achieve exactly what you are after - aka
prioritizing some memory consumers over others.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-09-25 6:52 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
2019-09-25 6:52 ` Michal Hocko [this message]
-- 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=20190925065248.GF23050@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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).