All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: vdavydov.dev@gmail.com, shakeelb@google.com,
	viro@zeniv.linux.org.uk, hannes@cmpxchg.org, mhocko@kernel.org,
	tglx@linutronix.de, pombredanne@nexb.com,
	stummala@codeaurora.org, gregkh@linuxfoundation.org,
	sfr@canb.auug.org.au, guro@fb.com, mka@chromium.org,
	penguin-kernel@I-love.SAKURA.ne.jp, chris@chris-wilson.co.uk,
	longman@redhat.com, minchan@kernel.org, ying.huang@intel.com,
	mgorman@techsingularity.net, jbacik@fb.com, linux@roeck-us.net,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	lirongqing@baidu.com, aryabinin@virtuozzo.com,
	akpm@linux-foundation.org
Subject: Re: [PATCH v8 03/17] mm: Assign id to every memcg-aware shrinker
Date: Tue, 3 Jul 2018 10:58:08 -0700	[thread overview]
Message-ID: <20180703175808.GC4834@bombadil.infradead.org> (raw)
In-Reply-To: <2d845a0d-d147-7250-747e-27e493b6a627@virtuozzo.com>

On Tue, Jul 03, 2018 at 06:46:57PM +0300, Kirill Tkhai wrote:
> shrinker_idr now contains only memcg-aware shrinkers, so all bits from memcg map
> may be potentially populated. In case of memcg-aware shrinkers and !memcg-aware
> shrinkers share the same numbers like you suggest, this will lead to increasing
> size of memcg maps, which is bad for memory consumption. So, memcg-aware shrinkers
> should to have its own IDR and its own numbers. The tricks like allocation big
> IDs for !memcg-aware shrinkers seem bad for me, since they make the code more
> complicated.

Do we really have so very many !memcg-aware shrinkers?

$ git grep -w register_shrinker |wc
     32     119    2221
$ git grep -w register_shrinker_prepared |wc
      4      13     268
(that's an overstatement; one of those is the declaration, one the definition,
and one an internal call, so we actually only have one caller of _prepared).

So it looks to me like your average system has one shrinker per
filesystem, one per graphics card, one per raid5 device, and a few
miscellaneous.  I'd be shocked if anybody had more than 100 shrinkers
registered on their laptop.

I think we should err on the side of simiplicity and just have one IDR for
every shrinker instead of playing games to solve a theoretical problem.

> > This will actually reduce the size of each shrinker and be more
> > cache-efficient when calling the shrinkers.  I think we can also get
> > rid of the shrinker_rwsem eventually, but let's leave it for now.
> 
> This patchset does not make the cache-efficient bad, since without the patchset the situation
> is so bad, that it's just impossible to talk about the cache efficiently,
> so let's leave lockless iteration/etc for the future works.

The situation is that bad /for your use case/.  Not so much for others.
You're introducing additional complexity here, and it'd be nice if we
can remove some of the complexity that's already there.

  reply	other threads:[~2018-07-03 17:58 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-03 15:08 [PATCH v8 00/17] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n)) Kirill Tkhai
2018-07-03 15:08 ` [PATCH v8 01/17] list_lru: Combine code under the same define Kirill Tkhai
2018-07-03 15:08 ` [PATCH v8 02/17] mm: Introduce CONFIG_MEMCG_KMEM as combination of CONFIG_MEMCG && !CONFIG_SLOB Kirill Tkhai
2018-07-03 15:09 ` [PATCH v8 03/17] mm: Assign id to every memcg-aware shrinker Kirill Tkhai
2018-07-03 15:27   ` Matthew Wilcox
2018-07-03 15:46     ` Shakeel Butt
2018-07-03 16:17       ` Kirill Tkhai
2018-07-03 17:00         ` Shakeel Butt
2018-07-03 17:32           ` Kirill Tkhai
2018-07-12 11:13             ` Kirill Tkhai
2018-07-12 11:19               ` Kirill Tkhai
2018-07-03 17:47       ` Matthew Wilcox
2018-07-03 20:39         ` Al Viro
2018-07-03 15:46     ` Kirill Tkhai
2018-07-03 17:58       ` Matthew Wilcox [this message]
2018-07-03 19:12         ` Kirill Tkhai
2018-07-03 19:19           ` Shakeel Butt
2018-07-03 19:25             ` Matthew Wilcox
2018-07-03 19:54               ` Shakeel Butt
2018-07-03 15:09 ` [PATCH v8 04/17] memcg: Move up for_each_mem_cgroup{, _tree} defines Kirill Tkhai
2018-07-03 15:09 ` [PATCH v8 05/17] mm: Assign memcg-aware shrinkers bitmap to memcg Kirill Tkhai
2018-07-03 20:50   ` Andrew Morton
2018-07-04 15:51     ` Kirill Tkhai
2018-07-05 22:10       ` Andrew Morton
2018-07-06 17:50         ` Vladimir Davydov
2018-07-05 22:50     ` Matthew Wilcox
2018-07-06 17:30     ` Vladimir Davydov
2018-07-03 15:09 ` [PATCH v8 06/17] mm: Refactoring in workingset_init() Kirill Tkhai
2018-07-03 15:09 ` [PATCH v8 07/17] fs: Refactoring in alloc_super() Kirill Tkhai
2018-07-03 15:09 ` [PATCH v8 08/17] fs: Propagate shrinker::id to list_lru Kirill Tkhai
2018-07-03 15:10 ` [PATCH v8 09/17] list_lru: Add memcg argument to list_lru_from_kmem() Kirill Tkhai
2018-07-03 15:10 ` [PATCH v8 10/17] list_lru: Pass dst_memcg argument to memcg_drain_list_lru_node() Kirill Tkhai
2018-07-03 15:10 ` [PATCH v8 11/17] list_lru: Pass lru " Kirill Tkhai
2018-07-03 15:10 ` [PATCH v8 12/17] mm: Export mem_cgroup_is_root() Kirill Tkhai
2018-07-03 15:10 ` [PATCH v8 13/17] mm: Set bit in memcg shrinker bitmap on first list_lru item apearance Kirill Tkhai
2018-07-03 20:54   ` Andrew Morton
2018-07-03 15:11 ` [PATCH v8 14/17] mm: Iterate only over charged shrinkers during memcg shrink_slab() Kirill Tkhai
2018-07-03 20:58   ` Andrew Morton
2018-07-04 14:56     ` Kirill Tkhai
2018-07-03 15:11 ` [PATCH v8 15/17] mm: Generalize shrink_slab() calls in shrink_node() Kirill Tkhai
2018-07-03 15:11 ` [PATCH v8 16/17] mm: Add SHRINK_EMPTY shrinker methods return value Kirill Tkhai
2018-07-03 15:11 ` [PATCH v8 17/17] mm: Clear shrinker bit if there are no objects related to memcg 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:
  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=20180703175808.GC4834@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=jbacik@fb.com \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@roeck-us.net \
    --cc=lirongqing@baidu.com \
    --cc=longman@redhat.com \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=mka@chromium.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=pombredanne@nexb.com \
    --cc=sfr@canb.auug.org.au \
    --cc=shakeelb@google.com \
    --cc=stummala@codeaurora.org \
    --cc=tglx@linutronix.de \
    --cc=vdavydov.dev@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=ying.huang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.