Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp6332794imm; Sun, 20 May 2018 00:27:45 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoUTu+HZJ2R/HwMeFuDp99yoLwNqZOtgX13g5G4WeNNHLPcbJiINSR8tV1QyBEUnxXF10rw X-Received: by 2002:a62:f713:: with SMTP id h19-v6mr15359524pfi.165.1526801265509; Sun, 20 May 2018 00:27:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526801265; cv=none; d=google.com; s=arc-20160816; b=vBxLnda+Zlr+uf4UM0vP/DCqKkYoqbIwHI4eI/jltO0gJyJOOqzYysN3YWuRthmpui FFvbGyv2TGGyw1kwUNc271SG/8+0rzqidK8vR0JHWdD29e2lR1rvpA3SMn8l1DuN9S74 kYrseagG+s0yp6HTXrmJvU8pHaxgxIRU6DV8wM05hClyl4FlN7xVu7EYeMEV+3CR39gY SwFSiDavDvoLxqtVMlJVmzQ2gLPzPoWpdzV9amCXhccqq5JKh2hg0zmdVHRJEvJ+tBWK TravO43I+E8BQiQep6yg1iJLur1n1wINMd2+cWVxEMTNjY09FUaPJOrVNYyFL+lLMt1V /Sug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=Q7hFadzAzHKpimIzUle7sr722gsa0DNs9S6GfNJTc5Y=; b=Yv+xD5pjtiLvegfAm6VALZ3Wi/Qt764kjeX6TU5DDVZ7tsLLlvurVvFiL8FudfHb78 3z1zmDYWzViFO2aZikZPEloR5SA3dRyVPD11OcKitQJYxhjkNG6WdRdPjI2E+pkOuwwN B0PBwyU3JdRttJ4aE+cHYqZAzkRBlQV+LgbR+39evDGw8hkUdU2zj5rGhZkHDTTCa3UI 2LFthwUjkgxad3AHSltrsmKlnGIaqwHPFMfG4IiKP1mKk/yNJl8ueKNnIsbN8SCzoa8v kZvJgdi1pnHsu98H3vQsIJKShf3kNlCXMykUjg/HbFvBWF+lldBtOjMIk1L5bv7B7skc zraw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=C3GD50De; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k75-v6si11034864pfk.369.2018.05.20.00.27.17; Sun, 20 May 2018 00:27:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=C3GD50De; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751434AbeETH1I (ORCPT + 99 others); Sun, 20 May 2018 03:27:08 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:43196 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750895AbeETH1G (ORCPT ); Sun, 20 May 2018 03:27:06 -0400 Received: by mail-lf0-f66.google.com with SMTP id n18-v6so19559488lfh.10 for ; Sun, 20 May 2018 00:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Q7hFadzAzHKpimIzUle7sr722gsa0DNs9S6GfNJTc5Y=; b=C3GD50DeA9aSH/DFei3ndYkDM6G6mErCvaJ5WC6tdJ6AHTJ5JVHRKwj6JgoEJ8vU2U 5RwXv3CRx9bTTJv9GmsHqr40QzoiqX091RiScRPH8kiIfK9OpUexmAu6JYGkGARyVpy5 b66SuU7EE3Q0NAigll4tia0WN1RpRt3TTFHFuEQsjbWkjOFZL79EDzhr6aXb2IocMBt9 RAVy334vXn+Yo9mFWvfERLwTsYJ92+TgQFIf+7AG2k5doXBFa5QDhUHtTKTQ0DXfW2iv u63uRXm1nbhlaj66GwEOPilJTM9BG/5qhgX1x9PKwjE7nh/3ySDPQ0bf8gPfqdRhaDrS OSww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Q7hFadzAzHKpimIzUle7sr722gsa0DNs9S6GfNJTc5Y=; b=GM5lHDQE8aYG4Y//9DKk4fs4DqALM++FXURQrqGC+uLORmVZg6ADq4XrQwiGjuGZr7 e8igO3VbWTs4DeqRoBWhKZ55rmeD1PtmKRKS461p8d6sth5fIW4AW/ZyvvWA1uQz+mxV lYL5qBiN1wx6iE/pfX4C41RHmzXM9cEER0qlRdi+Jjt1UitrssuxmFaCXpYEv2CvarNd GI81Q9/lDgQ7euz5o4WkedD+juTY8gyfA1Rwh4383Ze2Cm2IWo1h2NNJb5HBlS9ACAho GIV6gALbGOPZahdTgeA+qgrotldUC4becLDdKrr5lIQHwIkN+TqPK2gkciG/fzp6mOS0 2fDQ== X-Gm-Message-State: ALKqPweBmsuJF1NJnj+4H2eGx92JgVR4sq8et393yU2YclL1UhCpE8qV noBgaKYo/7oPsWMneeUogRpGfA== X-Received: by 2002:a19:d849:: with SMTP id p70-v6mr19445189lfg.36.1526801225233; Sun, 20 May 2018 00:27:05 -0700 (PDT) Received: from esperanza (81.5.110.211.dhcp.mipt-telecom.ru. [81.5.110.211]) by smtp.gmail.com with ESMTPSA id p5-v6sm1970018ljh.3.2018.05.20.00.27.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 20 May 2018 00:27:04 -0700 (PDT) Date: Sun, 20 May 2018 10:27:02 +0300 From: Vladimir Davydov To: Kirill Tkhai Cc: akpm@linux-foundation.org, 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, willy@infradead.org, lirongqing@baidu.com, aryabinin@virtuozzo.com Subject: Re: [PATCH v6 05/17] mm: Assign memcg-aware shrinkers bitmap to memcg Message-ID: <20180520072702.5ivoc5qxdbcus4td@esperanza> References: <152663268383.5308.8660992135988724014.stgit@localhost.localdomain> <152663295709.5308.12103481076537943325.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <152663295709.5308.12103481076537943325.stgit@localhost.localdomain> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2018 at 11:42:37AM +0300, Kirill Tkhai wrote: > Imagine a big node with many cpus, memory cgroups and containers. > Let we have 200 containers, every container has 10 mounts, > and 10 cgroups. All container tasks don't touch foreign > containers mounts. If there is intensive pages write, > and global reclaim happens, a writing task has to iterate > over all memcgs to shrink slab, before it's able to go > to shrink_page_list(). > > Iteration over all the memcg slabs is very expensive: > the task has to visit 200 * 10 = 2000 shrinkers > for every memcg, and since there are 2000 memcgs, > the total calls are 2000 * 2000 = 4000000. > > So, the shrinker makes 4 million do_shrink_slab() calls > just to try to isolate SWAP_CLUSTER_MAX pages in one > of the actively writing memcg via shrink_page_list(). > I've observed a node spending almost 100% in kernel, > making useless iteration over already shrinked slab. > > This patch adds bitmap of memcg-aware shrinkers to memcg. > The size of the bitmap depends on bitmap_nr_ids, and during > memcg life it's maintained to be enough to fit bitmap_nr_ids > shrinkers. Every bit in the map is related to corresponding > shrinker id. > > Next patches will maintain set bit only for really charged > memcg. This will allow shrink_slab() to increase its > performance in significant way. See the last patch for > the numbers. > > Signed-off-by: Kirill Tkhai > --- > include/linux/memcontrol.h | 14 +++++ > mm/memcontrol.c | 120 ++++++++++++++++++++++++++++++++++++++++++++ > mm/vmscan.c | 10 ++++ > 3 files changed, 144 insertions(+) > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index 996469bc2b82..e51c6e953d7a 100644 > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -112,6 +112,15 @@ struct lruvec_stat { > long count[NR_VM_NODE_STAT_ITEMS]; > }; > > +/* > + * Bitmap of shrinker::id corresponding to memcg-aware shrinkers, > + * which have elements charged to this memcg. > + */ > +struct memcg_shrinker_map { > + struct rcu_head rcu; > + unsigned long map[0]; > +}; > + > /* > * per-zone information in memory controller. > */ > @@ -125,6 +134,9 @@ struct mem_cgroup_per_node { > > struct mem_cgroup_reclaim_iter iter[DEF_PRIORITY + 1]; > > +#ifdef CONFIG_MEMCG_KMEM > + struct memcg_shrinker_map __rcu *shrinker_map; > +#endif > struct rb_node tree_node; /* RB tree node */ > unsigned long usage_in_excess;/* Set to the value by which */ > /* the soft limit is exceeded*/ > @@ -1261,6 +1273,8 @@ static inline int memcg_cache_id(struct mem_cgroup *memcg) > return memcg ? memcg->kmemcg_id : -1; > } > > +extern int memcg_expand_shrinker_maps(int new_id); > + > #else > #define for_each_memcg_cache_index(_idx) \ > for (; NULL; ) > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 023a1e9c900e..317a72137b95 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -320,6 +320,120 @@ EXPORT_SYMBOL(memcg_kmem_enabled_key); > > struct workqueue_struct *memcg_kmem_cache_wq; > > +static int memcg_shrinker_map_size; > +static DEFINE_MUTEX(memcg_shrinker_map_mutex); > + > +static void memcg_free_shrinker_map_rcu(struct rcu_head *head) > +{ > + kvfree(container_of(head, struct memcg_shrinker_map, rcu)); > +} > + > +static int memcg_expand_one_shrinker_map(struct mem_cgroup *memcg, > + int size, int old_size) Nit: No point in passing old_size here. You can instead use memcg_shrinker_map_size directly. > +{ > + struct memcg_shrinker_map *new, *old; > + int nid; > + > + lockdep_assert_held(&memcg_shrinker_map_mutex); > + > + for_each_node(nid) { > + old = rcu_dereference_protected( > + memcg->nodeinfo[nid]->shrinker_map, true); Nit: Sometimes you use mem_cgroup_nodeinfo() helper, sometimes you access mem_cgorup->nodeinfo directly. Please, be consistent. > + /* Not yet online memcg */ > + if (!old) > + return 0; > + > + new = kvmalloc(sizeof(*new) + size, GFP_KERNEL); > + if (!new) > + return -ENOMEM; > + > + /* Set all old bits, clear all new bits */ > + memset(new->map, (int)0xff, old_size); > + memset((void *)new->map + old_size, 0, size - old_size); > + > + rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_map, new); > + if (old) > + call_rcu(&old->rcu, memcg_free_shrinker_map_rcu); > + } > + > + return 0; > +} > + > +static void memcg_free_shrinker_maps(struct mem_cgroup *memcg) > +{ > + struct mem_cgroup_per_node *pn; > + struct memcg_shrinker_map *map; > + int nid; > + > + if (mem_cgroup_is_root(memcg)) > + return; > + > + for_each_node(nid) { > + pn = mem_cgroup_nodeinfo(memcg, nid); > + map = rcu_dereference_protected(pn->shrinker_map, true); > + if (map) > + kvfree(map); > + rcu_assign_pointer(pn->shrinker_map, NULL); > + } > +} > + > +static int memcg_alloc_shrinker_maps(struct mem_cgroup *memcg) > +{ > + struct memcg_shrinker_map *map; > + int nid, size, ret = 0; > + > + if (mem_cgroup_is_root(memcg)) > + return 0; > + > + mutex_lock(&memcg_shrinker_map_mutex); > + size = memcg_shrinker_map_size; > + for_each_node(nid) { > + map = kvzalloc(sizeof(*map) + size, GFP_KERNEL); > + if (!map) { > + memcg_free_shrinker_maps(memcg); Nit: Please don't call this function under the mutex as it isn't necessary. Set 'ret', break the loop, then check 'ret' after releasing the mutex, and call memcg_free_shrinker_maps() if it's not 0. > + ret = -ENOMEM; > + break; > + } > + rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_map, map); > + } > + mutex_unlock(&memcg_shrinker_map_mutex); > + > + return ret; > +} > + > +int memcg_expand_shrinker_maps(int nr) Nit: Please pass the new shrinker id to this function, not the max number of shrinkers out there - this will look more intuitive. And please add a comment to this function. Something like: Make sure memcg shrinker maps can store the given shrinker id. Expand the maps if necessary. > +{ > + int size, old_size, ret = 0; > + struct mem_cgroup *memcg; > + > + size = DIV_ROUND_UP(nr, BITS_PER_BYTE); Note, this will turn into DIV_ROUND_UP(id + 1, BITS_PER_BYTE) then. > + old_size = memcg_shrinker_map_size; Nit: old_size won't be needed if you make memcg_expand_one_shrinker_map use memcg_shrinker_map_size directly. > + if (size <= old_size) > + return 0; > + > + mutex_lock(&memcg_shrinker_map_mutex); > + if (!root_mem_cgroup) > + goto unlock; > + > + for_each_mem_cgroup(memcg) { > + if (mem_cgroup_is_root(memcg)) > + continue; > + ret = memcg_expand_one_shrinker_map(memcg, size, old_size); > + if (ret) > + goto unlock; > + } > +unlock: > + if (!ret) > + memcg_shrinker_map_size = size; > + mutex_unlock(&memcg_shrinker_map_mutex); > + return ret; > +} > +#else /* CONFIG_MEMCG_KMEM */ > +static int memcg_alloc_shrinker_maps(struct mem_cgroup *memcg) > +{ > + return 0; > +} > +static void memcg_free_shrinker_maps(struct mem_cgroup *memcg) { } > #endif /* CONFIG_MEMCG_KMEM */ > > /** > @@ -4482,6 +4596,11 @@ static int mem_cgroup_css_online(struct cgroup_subsys_state *css) > { > struct mem_cgroup *memcg = mem_cgroup_from_css(css); > > + if (memcg_alloc_shrinker_maps(memcg)) { > + mem_cgroup_id_remove(memcg); > + return -ENOMEM; > + } > + > /* Online state pins memcg ID, memcg ID pins CSS */ > atomic_set(&memcg->id.ref, 1); > css_get(css); > @@ -4534,6 +4653,7 @@ static void mem_cgroup_css_free(struct cgroup_subsys_state *css) > vmpressure_cleanup(&memcg->vmpressure); > cancel_work_sync(&memcg->high_work); > mem_cgroup_remove_from_trees(memcg); > + memcg_free_shrinker_maps(memcg); > memcg_free_kmem(memcg); > mem_cgroup_free(memcg); > } > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 3de12a9bdf85..f09ea20d7270 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -171,6 +171,7 @@ static DECLARE_RWSEM(shrinker_rwsem); > > #ifdef CONFIG_MEMCG_KMEM > static DEFINE_IDR(shrinker_idr); > +static int memcg_shrinker_nr_max; Nit: Please rename it to shrinker_id_max and make it store max shrinker id, not the max number shrinkers that have ever been allocated. This will make it easier to understand IMO. Also, this variable doesn't belong to this patch as you don't really need it to expaned mem cgroup maps. Let's please move it to patch 3 (the one that introduces shrinker_idr). > > static int prealloc_memcg_shrinker(struct shrinker *shrinker) > { > @@ -181,6 +182,15 @@ static int prealloc_memcg_shrinker(struct shrinker *shrinker) > ret = id = idr_alloc(&shrinker_idr, shrinker, 0, 0, GFP_KERNEL); > if (ret < 0) > goto unlock; > + > + if (id >= memcg_shrinker_nr_max) { > + if (memcg_expand_shrinker_maps(id + 1)) { > + idr_remove(&shrinker_idr, id); > + goto unlock; > + } > + memcg_shrinker_nr_max = id + 1; > + } > + Then we'll have here: if (memcg_expaned_shrinker_maps(id)) { idr_remove(shrinker_idr, id); goto unlock; } and from patch 3: shrinker_id_max = MAX(shrinker_id_max, id); > shrinker->id = id; > ret = 0; > unlock: >