LKML Archive on
help / color / mirror / Atom feed
From: Dave Chinner <>
To: Kirill Tkhai <>
Cc: Michal Hocko <>,,,,
Subject: Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim
Date: Fri, 23 Mar 2018 10:46:13 +1100	[thread overview]
Message-ID: <20180322234613.GD18129@dastard> (raw)
In-Reply-To: <>

On Thu, Mar 22, 2018 at 07:52:37PM +0300, Kirill Tkhai wrote:
> Here is the problem I'm solving:

Oh, finally you tell me what the problem is that you're trying to
solve. I *asked this several times* and got no response. Thank you
for wasting so much of my time.

> Current shrinker is not scalable. Then there are many memcg and mounts,
> the time of iteration shrink_slab() in case of global reclaim can
> take much time. There is times of shrink_slab() by the link. A node
> with 200 containers may waste 4 seconds on global reclaim just to
> iterate over all shrinkers for all cgroups, call shrinker::count_objects()
> and receive 0 zero objects.

So, your problem is the way the memcgs were tacked onto the side
of the list_lru infrastructure and are iterated, which has basically
nothing to do with the way the low level XFS inode shrinker behaves.

/me looks at the patches

/me shudders at the thought of external "cache has freeable items"
control for the shrinking of vfs caches.

Biggest problem I see with this is the scope for coherency bugs ini
the "memcg shrinker has freeable items" tracking. If that happens,
there's no way of getting that memcg to run it's shrinker ever
again. That seems very, very fragile and likely to be an endless
source of OOM bugs. The whole point of the shrinker polling
infrastructure is that it is not susceptible to this sort of bug.

Really, the problem is that there's no separate list of memcg aware
shrinkers, so every registered shrinker has to be iterated just to
find the one shrinker that is memcg aware.

So why not just do the simple thing which is create a separate
"memcg-aware" shrinker list (i.e. create shrinker_list_memcg
alongside shrinker_list) and only iterate the shrinker_list_memcg
when a memcg is passed to shrink_slab()?

That means we'll only run 2 shrinkers per memcg at most (sueprblock
and working set) per memcg reclaim call. That's a simple 10-20 line
change, not a whole mess of new code and issues...

> Can't we call shrink of shared objects only for top memcg? Something like
> this:

What's a "shared object", and how is it any different to a normal
slab cache object?


Dave Chinner

  reply	other threads:[~2018-03-22 23:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 15:01 Kirill Tkhai
2018-03-15 15:53 ` Darrick J. Wong
2018-03-15 16:06   ` Kirill Tkhai
2018-03-15 17:49 ` Michal Hocko
2018-03-15 19:28   ` Kirill Tkhai
2018-03-15 19:32     ` Michal Hocko
2018-03-15 19:42       ` Kirill Tkhai
2018-03-15 23:03     ` Dave Chinner
2018-03-16  8:55       ` Kirill Tkhai
2018-03-16 21:39         ` Dave Chinner
2018-03-19 11:06           ` Kirill Tkhai
2018-03-19 11:25             ` Kirill Tkhai
2018-03-20  0:18             ` Dave Chinner
2018-03-20 13:15               ` Kirill Tkhai
2018-03-20 14:34                 ` Dave Chinner
2018-03-21 16:15                   ` Kirill Tkhai
2018-03-22  5:01                     ` Dave Chinner
2018-03-22 16:52                       ` Kirill Tkhai
2018-03-22 23:46                         ` Dave Chinner [this message]
2018-03-23 12:39                           ` Kirill Tkhai
2018-03-26  2:37                             ` Dave Chinner
2018-03-26 11:16                               ` Kirill Tkhai

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180322234613.GD18129@dastard \ \ \ \ \ \ \ \
    --subject='Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).