All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: viro@zeniv.linux.org.uk, hannes@cmpxchg.org, mhocko@kernel.org,
	akpm@linux-foundation.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,
	hillf.zj@alibaba-inc.com, ying.huang@intel.com,
	mgorman@techsingularity.net, shakeelb@google.com, jbacik@fb.com,
	linux@roeck-us.net, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, willy@infradead.org
Subject: Re: [PATCH 09/10] mm: Iterate only over charged shrinkers during memcg shrink_slab()
Date: Mon, 26 Mar 2018 18:33:34 +0300	[thread overview]
Message-ID: <161e6bcb-82d9-ae19-0eb7-d3e913d139ff@virtuozzo.com> (raw)
In-Reply-To: <20180324201109.r4udxibbg4t23apg@esperanza>

On 24.03.2018 23:11, Vladimir Davydov wrote:
> On Wed, Mar 21, 2018 at 04:22:51PM +0300, Kirill Tkhai wrote:
>> Using the preparations made in previous patches, in case of memcg
>> shrink, we may avoid shrinkers, which are not set in memcg's shrinkers
>> bitmap. To do that, we separate iterations over memcg-aware and
>> !memcg-aware shrinkers, and memcg-aware shrinkers are chosen
>> via for_each_set_bit() from the bitmap. In case of big nodes,
>> having many isolated environments, this gives significant
>> performance growth. See next patch for the details.
>>
>> Note, that the patch does not respect to empty memcg shrinkers,
>> since we never clear the bitmap bits after we set it once.
>> Their shrinkers will be called again, with no shrinked objects
>> as result. This functionality is provided by next patch.
>>
>> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
>> ---
>>  mm/vmscan.c |   54 +++++++++++++++++++++++++++++++++++++++++-------------
>>  1 file changed, 41 insertions(+), 13 deletions(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 265cf069b470..e1fd16bc7a9b 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -327,6 +327,8 @@ static int alloc_shrinker_id(struct shrinker *shrinker)
>>  
>>  	if (!(shrinker->flags & SHRINKER_MEMCG_AWARE))
>>  		return 0;
>> +	BUG_ON(!(shrinker->flags & SHRINKER_NUMA_AWARE));
>> +
>>  retry:
>>  	ida_pre_get(&bitmap_id_ida, GFP_KERNEL);
>>  	down_write(&bitmap_rwsem);
>> @@ -366,7 +368,8 @@ static void add_shrinker(struct shrinker *shrinker)
>>  	down_write(&shrinker_rwsem);
>>  	if (shrinker->flags & SHRINKER_MEMCG_AWARE)
>>  		mcg_shrinkers[shrinker->id] = shrinker;
>> -	list_add_tail(&shrinker->list, &shrinker_list);
>> +	else
>> +		list_add_tail(&shrinker->list, &shrinker_list);
> 
> I don't think we should remove per-memcg shrinkers from the global
> shrinker list - this is confusing. It won't be critical if we iterate
> over all shrinkers on global reclaim, will it?

It depends on number of all shrinkers. And this is excess actions, we have to do.
Accessing their memory we flush cpu caches in some way. So, if there is no a reason
we really need them, I'd removed them from the list.

>>  	up_write(&shrinker_rwsem);
>>  }
>>  
>> @@ -701,6 +705,39 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>>  	if (!down_read_trylock(&shrinker_rwsem))
>>  		goto out;
>>  
>> +#if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
>> +	if (!memcg_kmem_enabled() || memcg) {
>> +		struct shrinkers_map *map;
>> +		int i;
>> +
>> +		map = rcu_dereference_protected(SHRINKERS_MAP(memcg), true);
>> +		if (map) {
>> +			for_each_set_bit(i, map->map[nid], bitmap_nr_ids) {
>> +				struct shrink_control sc = {
>> +					.gfp_mask = gfp_mask,
>> +					.nid = nid,
>> +					.memcg = memcg,
>> +				};
>> +
>> +				shrinker = mcg_shrinkers[i];
>> +				if (!shrinker) {
>> +					clear_bit(i, map->map[nid]);
>> +					continue;
>> +				}
>> +				freed += do_shrink_slab(&sc, shrinker, priority);
>> +
>> +				if (rwsem_is_contended(&shrinker_rwsem)) {
>> +					freed = freed ? : 1;
>> +					goto unlock;
>> +				}
>> +			}
>> +		}
>> +
>> +		if (memcg_kmem_enabled() && memcg)
>> +			goto unlock;
> 
> May be, factor this out to a separate function, say shrink_slab_memcg?
> Just for the sake of code legibility.

Good idea, thanks.

Kirill

  reply	other threads:[~2018-03-26 15:33 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 13:21 [PATCH 00/10] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n)) Kirill Tkhai
2018-03-21 13:21 ` [PATCH 01/10] mm: Assign id to every memcg-aware shrinker Kirill Tkhai
2018-03-24 18:40   ` Vladimir Davydov
2018-03-26 15:09     ` Kirill Tkhai
2018-03-26 15:14       ` Matthew Wilcox
2018-03-26 15:38         ` Kirill Tkhai
2018-03-27  9:15       ` Vladimir Davydov
2018-03-27 15:09         ` Kirill Tkhai
2018-03-27 15:48           ` Vladimir Davydov
2018-03-28 10:30             ` Kirill Tkhai
2018-03-28 11:02               ` Vladimir Davydov
2018-03-21 13:21 ` [PATCH 02/10] mm: Maintain memcg-aware shrinkers in mcg_shrinkers array Kirill Tkhai
2018-03-24 18:45   ` Vladimir Davydov
2018-03-26 15:20     ` Kirill Tkhai
2018-03-26 15:34       ` Matthew Wilcox
2018-03-27  9:18       ` Vladimir Davydov
2018-03-27 15:30         ` Kirill Tkhai
2018-03-21 13:21 ` [PATCH 03/10] mm: Assign memcg-aware shrinkers bitmap to memcg Kirill Tkhai
2018-03-21 14:56   ` Matthew Wilcox
2018-03-21 15:12     ` Kirill Tkhai
2018-03-21 15:26       ` Matthew Wilcox
2018-03-21 15:43         ` Kirill Tkhai
2018-03-21 16:20           ` Matthew Wilcox
2018-03-21 16:42             ` Kirill Tkhai
2018-03-21 17:54               ` Matthew Wilcox
2018-03-22 16:39                 ` Kirill Tkhai
2018-03-23  9:06   ` kbuild test robot
2018-03-23  9:06     ` kbuild test robot
2018-03-23 11:26     ` Kirill Tkhai
2018-03-24 19:25   ` Vladimir Davydov
2018-03-26 15:29     ` Kirill Tkhai
2018-03-27 10:00       ` Vladimir Davydov
2018-03-27 15:17         ` Kirill Tkhai
2018-03-21 13:21 ` [PATCH 04/10] fs: Propagate shrinker::id to list_lru Kirill Tkhai
2018-03-24 18:50   ` Vladimir Davydov
2018-03-26 15:29     ` Kirill Tkhai
2018-03-21 13:22 ` [PATCH 05/10] list_lru: Add memcg argument to list_lru_from_kmem() Kirill Tkhai
2018-04-02  3:17   ` [lkp-robot] [list_lru] 42658d54ce: BUG:unable_to_handle_kernel kernel test robot
2018-04-02  3:17     ` kernel test robot
2018-04-02  3:17     ` kernel test robot
2018-04-02  8:51     ` Kirill Tkhai
2018-04-02  8:51       ` Kirill Tkhai
2018-03-21 13:22 ` [PATCH 06/10] list_lru: Pass dst_memcg argument to memcg_drain_list_lru_node() Kirill Tkhai
2018-03-24 19:32   ` Vladimir Davydov
2018-03-26 15:30     ` Kirill Tkhai
2018-03-28 14:49       ` Kirill Tkhai
2018-03-21 13:22 ` [PATCH 07/10] list_lru: Pass lru " Kirill Tkhai
2018-03-21 13:22 ` [PATCH 08/10] mm: Set bit in memcg shrinker bitmap on first list_lru item apearance Kirill Tkhai
2018-03-24 19:45   ` Vladimir Davydov
2018-03-26 15:31     ` Kirill Tkhai
2018-03-21 13:22 ` [PATCH 09/10] mm: Iterate only over charged shrinkers during memcg shrink_slab() Kirill Tkhai
2018-03-24 20:11   ` Vladimir Davydov
2018-03-26 15:33     ` Kirill Tkhai [this message]
2018-03-21 13:23 ` [PATCH 10/10] mm: Clear shrinker bit if there are no objects related to memcg Kirill Tkhai
2018-03-24 20:33   ` Vladimir Davydov
2018-03-26 15:37     ` Kirill Tkhai
2018-03-21 13:23 ` [PATCH 00/10] Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n)) 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=161e6bcb-82d9-ae19-0eb7-d3e913d139ff@virtuozzo.com \
    --to=ktkhai@virtuozzo.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=jbacik@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@roeck-us.net \
    --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=willy@infradead.org \
    --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.