[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180705151030.c67eb9a989c5f0023a53d415@linux-foundation.org>
Date: Thu, 5 Jul 2018 15:10:30 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Kirill Tkhai <ktkhai@...tuozzo.com>
Cc: vdavydov.dev@...il.com, shakeelb@...gle.com,
viro@...iv.linux.org.uk, hannes@...xchg.org, mhocko@...nel.org,
tglx@...utronix.de, pombredanne@...b.com, stummala@...eaurora.org,
gregkh@...uxfoundation.org, sfr@...b.auug.org.au, guro@...com,
mka@...omium.org, penguin-kernel@...ove.SAKURA.ne.jp,
chris@...is-wilson.co.uk, longman@...hat.com, minchan@...nel.org,
ying.huang@...el.com, mgorman@...hsingularity.net, jbacik@...com,
linux@...ck-us.net, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, willy@...radead.org, lirongqing@...du.com,
aryabinin@...tuozzo.com
Subject: Re: [PATCH v8 05/17] mm: Assign memcg-aware shrinkers bitmap to
memcg
On Wed, 4 Jul 2018 18:51:12 +0300 Kirill Tkhai <ktkhai@...tuozzo.com> wrote:
> > - why aren't we decreasing shrinker_nr_max in
> > unregister_memcg_shrinker()? That's easy to do, avoids pointless
> > work in shrink_slab_memcg() and avoids memory waste in future
> > prealloc_memcg_shrinker() calls.
>
> You sure, but there are some things. Initially I went in the same way
> as memcg_nr_cache_ids is made and just took the same x2 arithmetic.
> It never decreases, so it looked good to make shrinker maps like it.
> It's the only reason, so, it should not be a problem to rework.
>
> The only moment is Vladimir strongly recommends modularity, i.e.
> to have memcg_shrinker_map_size and shrinker_nr_max as different variables.
For what reasons?
> After the rework we won't be able to have this anymore, since memcontrol.c
> will have to know actual shrinker_nr_max value and it will have to be exported.
>
> Could this be a problem?
Vladimir?
Powered by blists - more mailing lists