linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hillf Danton <hdanton@sina.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Hillf Danton <hdanton@sina.com>, linux-mm <linux-mm@kvack.org>,
	Rong Chen <rong.a.chen@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC v3] memcg: add memcg lru
Date: Mon, 18 Nov 2019 20:50:14 +0800	[thread overview]
Message-ID: <20191118125014.11516-1-hdanton@sina.com> (raw)


On Mon, 18 Nov 2019 11:29:50 +0100 Michal Hocko wrote:
> 
> On Sun 17-11-19 19:35:26, Hillf Danton wrote:
> > 
> > Currently soft limit reclaim (slr) is frozen, see
> > Documentation/admin-guide/cgroup-v2.rst for reasons.
> > 
> > This work adds memcg hook into kswapd's logic to bypass slr, paving
> > a brick for its cleanup later.
> > 
> > After b23afb93d317 ("memcg: punt high overage reclaim to
> > return-to-userland path"), high limit breachers (hlb) are reclaimed
> > one after another spiraling up through the memcg hierarchy before
> > returning to userspace.
> > 
> > The current memcg high work helps to add the lru because we get to
> > collect hlb at zero price and in particular without adding changes
> > to the high work's behavior.
> > 
> > Then a fifo list, which is essencially a simple copy of the page lru,
> > is needed to facilitate queuing up hlb and ripping pages off them in
> > round robin once kswapd starts doing its job.
> > 
> > Finally new hook is added with slr's two problems addressed i.e.
> > hierarchy-unaware reclaim and overreclaim.
> > 
> > Thanks to Rong Chen for testing.
> 
Hey Michal

Thanks for your comments, this time and previous.

> You have ignored the previous review feedback again [1]. I have nacked
> the patch on grounds that it is completely missing any real use case
> scenario or any numbers suggesting there is an actual improvement.
> 
You are right though around half.

After another peep at your comment on v2, I think you didn't approve
the change added in high work to defer reclaim until kswapd becomes
active with good reasoning. That defer is cut in v3.

The added lru will take the place of the current slr, so slr's use
cases apply to it with no exception, yes? Please feel free let us
know what use cases else you may have interests in.

And the concerned improvement is just on the table, Sir, if we fail
to see regressions following lru, with no need to say the price we
pay for maintaining hlb is close to zero for instance among others.

Hillf

> Please do not post new versions until you make those things clear.
> 
> [1] http://lkml.kernel.org/r/20191029083730.GC31513@dhcp22.suse.cz
> -- 
> Michal Hocko
> SUSE Labs



             reply	other threads:[~2019-11-18 12:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18 12:50 Hillf Danton [this message]
2019-11-18 14:04 ` Michal Hocko
  -- strict thread matches above, loose matches on Subject: below --
2019-11-17 11:35 Hillf Danton
2019-11-18 10:29 ` 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=20191118125014.11516-1-hdanton@sina.com \
    --to=hdanton@sina.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=rong.a.chen@intel.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