Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1561142 > unrolled thread

[PATCH 10/10] slab: use memcg_kmem_cache_wq for slab destruction operations

Started byTejun Heo <tj@kernel.org>
First post2017-01-18 01:00 +0100
Last post2017-01-29 17:40 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 10/10] slab: use memcg_kmem_cache_wq for slab destruction operations Tejun Heo <tj@kernel.org> - 2017-01-18 01:00 +0100
    Re: [PATCH 10/10] slab: use memcg_kmem_cache_wq for slab destruction  operations Vladimir Davydov <vdavydov@tarantool.org> - 2017-01-29 17:40 +0100

#1561142 — [PATCH 10/10] slab: use memcg_kmem_cache_wq for slab destruction operations

FromTejun Heo <tj@kernel.org>
Date2017-01-18 01:00 +0100
Subject[PATCH 10/10] slab: use memcg_kmem_cache_wq for slab destruction operations
Message-ID<t0LPs-54F-33@gated-at.bofh.it>
If there's contention on slab_mutex, queueing the per-cache
destruction work item on the system_wq can unnecessarily create and
tie up a lot of kworkers.

Rename memcg_kmem_cache_create_wq to memcg_kmem_cache_wq and make it
global and use that workqueue for the destruction work items too.
While at it, convert the workqueue from an unbound workqueue to a
per-cpu one with concurrency limited to 1.  It's generally preferable
to use per-cpu workqueues and concurrency limit of 1 is safe enough.

This is suggested by Joonsoo Kim.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Jay Vana <jsvana@fb.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 include/linux/memcontrol.h |  1 +
 mm/memcontrol.c            | 16 ++++++++--------
 mm/slab_common.c           |  2 +-
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 4de925c..67f3303 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -810,6 +810,7 @@ void memcg_kmem_uncharge(struct page *page, int order);
 
 #if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
 extern struct static_key_false memcg_kmem_enabled_key;
+extern struct workqueue_struct *memcg_kmem_cache_wq;
 
 extern int memcg_nr_cache_ids;
 void memcg_get_cache_ids(void);
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a2b20f7f..8757403 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -317,6 +317,8 @@ void memcg_put_cache_ids(void)
 DEFINE_STATIC_KEY_FALSE(memcg_kmem_enabled_key);
 EXPORT_SYMBOL(memcg_kmem_enabled_key);
 
+struct workqueue_struct *memcg_kmem_cache_wq;
+
 #endif /* !CONFIG_SLOB */
 
 /**
@@ -2145,8 +2147,6 @@ struct memcg_kmem_cache_create_work {
 	struct work_struct work;
 };
 
-static struct workqueue_struct *memcg_kmem_cache_create_wq;
-
 static void memcg_kmem_cache_create_func(struct work_struct *w)
 {
 	struct memcg_kmem_cache_create_work *cw =
@@ -2178,7 +2178,7 @@ static void __memcg_schedule_kmem_cache_create(struct mem_cgroup *memcg,
 	cw->cachep = cachep;
 	INIT_WORK(&cw->work, memcg_kmem_cache_create_func);
 
-	queue_work(memcg_kmem_cache_create_wq, &cw->work);
+	queue_work(memcg_kmem_cache_wq, &cw->work);
 }
 
 static void memcg_schedule_kmem_cache_create(struct mem_cgroup *memcg,
@@ -5780,12 +5780,12 @@ static int __init mem_cgroup_init(void)
 #ifndef CONFIG_SLOB
 	/*
 	 * Kmem cache creation is mostly done with the slab_mutex held,
-	 * so use a special workqueue to avoid stalling all worker
-	 * threads in case lots of cgroups are created simultaneously.
+	 * so use a workqueue with limited concurrency to avoid stalling
+	 * all worker threads in case lots of cgroups are created and
+	 * destroyed simultaneously.
 	 */
-	memcg_kmem_cache_create_wq =
-		alloc_ordered_workqueue("memcg_kmem_cache_create", 0);
-	BUG_ON(!memcg_kmem_cache_create_wq);
+	memcg_kmem_cache_wq = alloc_workqueue("memcg_kmem_cache", 0, 1);
+	BUG_ON(!memcg_kmem_cache_wq);
 #endif
 
 	cpuhp_setup_state_nocalls(CPUHP_MM_MEMCQ_DEAD, "mm/memctrl:dead", NULL,
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 32610d1..5e6a98c 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -656,7 +656,7 @@ static void kmemcg_deactivate_rcufn(struct rcu_head *head)
 	 * initialized eariler.
 	 */
 	INIT_WORK(&s->memcg_params.deact_work, kmemcg_deactivate_workfn);
-	schedule_work(&s->memcg_params.deact_work);
+	queue_work(memcg_kmem_cache_wq, &s->memcg_params.deact_work);
 }
 
 /**
-- 
2.9.3

[toc] | [next] | [standalone]


#1569229 — Re: [PATCH 10/10] slab: use memcg_kmem_cache_wq for slab destruction operations

FromVladimir Davydov <vdavydov@tarantool.org>
Date2017-01-29 17:40 +0100
SubjectRe: [PATCH 10/10] slab: use memcg_kmem_cache_wq for slab destruction operations
Message-ID<t50Gf-Ut-27@gated-at.bofh.it>
In reply to#1561142
On Tue, Jan 17, 2017 at 03:54:11PM -0800, Tejun Heo wrote:
> If there's contention on slab_mutex, queueing the per-cache
> destruction work item on the system_wq can unnecessarily create and
> tie up a lot of kworkers.
> 
> Rename memcg_kmem_cache_create_wq to memcg_kmem_cache_wq and make it
> global and use that workqueue for the destruction work items too.
> While at it, convert the workqueue from an unbound workqueue to a
> per-cpu one with concurrency limited to 1.  It's generally preferable
> to use per-cpu workqueues and concurrency limit of 1 is safe enough.
> 
> This is suggested by Joonsoo Kim.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Jay Vana <jsvana@fb.com>
> Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>

Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web