[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <799ae1e9-1f16-baf9-6bfa-305f31ae2794@virtuozzo.com>
Date: Thu, 10 May 2018 12:42:37 +0300
From: Kirill Tkhai <ktkhai@...tuozzo.com>
To: Andrew Morton <akpm@...ux-foundation.org>
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 v4 01/13] mm: Assign id to every memcg-aware shrinker
On 10.05.2018 01:55, Andrew Morton wrote:
> On Wed, 09 May 2018 14:56:55 +0300 Kirill Tkhai <ktkhai@...tuozzo.com> wrote:
>
>> The patch introduces shrinker::id number, which is used to enumerate
>> memcg-aware shrinkers. The number start from 0, and the code tries
>> to maintain it as small as possible.
>>
>> This will be used as to represent a memcg-aware shrinkers in memcg
>> shrinkers map.
>>
>> ...
>>
>> --- a/fs/super.c
>> +++ b/fs/super.c
>> @@ -248,6 +248,9 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags,
>> s->s_time_gran = 1000000000;
>> s->cleancache_poolid = CLEANCACHE_NO_POOL;
>>
>> +#if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
>
> It would be more conventional to do this logic in Kconfig - define a
> new MEMCG_SHRINKER which equals MEMCG && !SLOB.
>
> This ifdef occurs a distressing number of times in the patchset :( I
> wonder if there's something we can do about that.
>
> Also, why doesn't it work with slob? Please describe the issue in the
> changelogs somewhere.
All currently existing memcg-aware shrinkers are based on list_lru, which
does not introduce separate memcg lists for SLOB case. So, the optimization
made by this patchset is not need there.
I'll make MEMCG_SHRINKER in next version like you suggested. Even if we have
no such shrinkers at the moment, we may have them in the future, and this will
be useful anyway.
> It's a pretty big patchset. I *could* merge it up in the hope that
> someone is planning do do a review soon. But is there such a person?
Thanks,
Kirill
Powered by blists - more mailing lists