linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Roman Gushchin <guro@fb.com>
Cc: Rik van Riel <riel@surriel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com, Josef Bacik <jbacik@fb.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: slowly shrink slabs with a relatively small number of objects
Date: Tue, 4 Sep 2018 20:06:31 +0200	[thread overview]
Message-ID: <20180904180631.GR14951@dhcp22.suse.cz> (raw)
In-Reply-To: <20180904175243.GA4889@tower.DHCP.thefacebook.com>

On Tue 04-09-18 10:52:46, Roman Gushchin wrote:
> On Tue, Sep 04, 2018 at 06:14:31PM +0200, Michal Hocko wrote:
[...]
> > I am not opposing your patch but I am trying to figure out whether that
> > is the best approach.
> 
> I don't think the current logic does make sense. Why should cgroups
> with less than 4k kernel objects be excluded from being scanned?

How is it any different from the the LRU reclaim? Maybe it is just not
that visible because there usually more pages there. But in principle it
is the same issue AFAICS.

> Reparenting of all pages is definitely an option to consider,
> but it's not free in any case, so if there is no problem,
> why should we? Let's keep it as a last measure. In my case,
> the proposed patch works perfectly: the number of dying cgroups
> jumps around 100, where it grew steadily to 2k and more before.

Let me emphasise that I am not opposing the patch. I just think that we
have made some decisions which are not ideal but I would really like to
prevent from building workarounds on top. If we have to reconsider some
of those decisions then let's do it. Maybe the priority scaling is just
too coarse and what seem to work work for normal LRUs doesn't work for
shrinkers.

> I believe that reparenting of LRU lists is required to minimize
> the number of LRU lists to scan, but I'm not sure.

Well, we do have more lists to scan for normal LRUs. It is true that
shrinkers add multiplining factor to that but in principle I guess we
really want to distinguish dead memcgs because we do want to reclaim
those much more than the rest. Those objects are basically of no use
just eating resources. The pagecache has some chance to be reused at
least but I fail to see why we should keep kernel objects around. Sure,
some of them might be harder to reclaim due to different life time and
internal object management but this doesn't change the fact that we
should try hard to reclaim those. So my gut feeling tells me that we
should have a way to distinguish them.

Btw. I do not see Vladimir on the CC list. Added (the thread starts
here http://lkml.kernel.org/r/20180831203450.2536-1-guro@fb.com)
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2018-09-04 18:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 20:34 [PATCH] mm: slowly shrink slabs with a relatively small number of objects Roman Gushchin
2018-08-31 21:15 ` Rik van Riel
2018-08-31 21:31   ` Roman Gushchin
2018-09-01  1:27     ` Rik van Riel
2018-09-03 18:29     ` Michal Hocko
2018-09-03 20:28       ` Roman Gushchin
2018-09-04  7:00         ` Michal Hocko
2018-09-04 15:34           ` Roman Gushchin
2018-09-04 16:14             ` Michal Hocko
2018-09-04 17:52               ` Roman Gushchin
2018-09-04 18:06                 ` Michal Hocko [this message]
2018-09-04 18:07                   ` Michal Hocko
2018-09-04 20:34                 ` Vladimir Davydov

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=20180904180631.GR14951@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=jbacik@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@surriel.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;
as well as URLs for NNTP newsgroup(s).