All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20161004131417.GC1862@esperanza>

diff --git a/a/1.txt b/N1/1.txt
index 3149d27..0c324eb 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -42,3 +42,78 @@ On Mon, Oct 03, 2016 at 03:19:31PM +0200, Michal Hocko wrote:
 Yeah, you're right - I thought max_active implies ordering, but it
 doesn't. Then we can use an ordered workqueue. Here's the updated
 patch:
+
+>From 10f5f126800912c6a4b78a8b615138c1322694ad Mon Sep 17 00:00:00 2001
+From: Vladimir Davydov <vdavydov.dev@gmail.com>
+Date: Sat, 1 Oct 2016 16:39:09 +0300
+Subject: [PATCH] mm: memcontrol: use special workqueue for creating per-memcg
+ caches
+
+Creating a lot of cgroups at the same time might stall all worker
+threads with kmem cache creation works, because kmem cache creation is
+done with the slab_mutex held. The problem was amplified by commits
+801faf0db894 ("mm/slab: lockless decision to grow cache") in case of
+SLAB and 81ae6d03952c ("mm/slub.c: replace kick_all_cpus_sync() with
+synchronize_sched() in kmem_cache_shrink()") in case of SLUB, which
+increased the maximal time the slab_mutex can be held.
+
+To prevent that from happening, let's use a special ordered single
+threaded workqueue for kmem cache creation. This shouldn't introduce any
+functional changes regarding how kmem caches are created, as the work
+function holds the global slab_mutex during its whole runtime anyway,
+making it impossible to run more than one work at a time. By using a
+single threaded workqueue, we just avoid creating a thread per each
+work. Ordering is required to avoid a situation when a cgroup's work is
+put off indefinitely because there are other cgroups to serve, in other
+words to guarantee fairness.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=172981
+Signed-off-by: Vladimir Davydov <vdavydov.dev@gmail.com>
+Reported-by: Doug Smythies <dsmythies@telus.net>
+Cc: Christoph Lameter <cl@linux.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Pekka Enberg <penberg@kernel.org>
+
+diff --git a/mm/memcontrol.c b/mm/memcontrol.c
+index 4be518d4e68a..8d753d87ca37 100644
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -2175,6 +2175,8 @@ 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 =
+@@ -2206,7 +2208,7 @@ static void __memcg_schedule_kmem_cache_create(struct mem_cgroup *memcg,
+ 	cw->cachep = cachep;
+ 	INIT_WORK(&cw->work, memcg_kmem_cache_create_func);
+ 
+-	schedule_work(&cw->work);
++	queue_work(memcg_kmem_cache_create_wq, &cw->work);
+ }
+ 
+ static void memcg_schedule_kmem_cache_create(struct mem_cgroup *memcg,
+@@ -5794,6 +5796,17 @@ static int __init mem_cgroup_init(void)
+ {
+ 	int cpu, node;
+ 
++#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.
++	 */
++	memcg_kmem_cache_create_wq =
++		alloc_ordered_workqueue("memcg_kmem_cache_create", 0);
++	BUG_ON(!memcg_kmem_cache_create_wq);
++#endif
++
+ 	hotcpu_notifier(memcg_cpu_hotplug_callback, 0);
+ 
+ 	for_each_possible_cpu(cpu)
diff --git a/a/content_digest b/N1/content_digest
index 0eceefb..6993df7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -54,6 +54,81 @@
  "\n"
  "Yeah, you're right - I thought max_active implies ordering, but it\n"
  "doesn't. Then we can use an ordered workqueue. Here's the updated\n"
- patch:
+ "patch:\n"
+ "\n"
+ ">From 10f5f126800912c6a4b78a8b615138c1322694ad Mon Sep 17 00:00:00 2001\n"
+ "From: Vladimir Davydov <vdavydov.dev@gmail.com>\n"
+ "Date: Sat, 1 Oct 2016 16:39:09 +0300\n"
+ "Subject: [PATCH] mm: memcontrol: use special workqueue for creating per-memcg\n"
+ " caches\n"
+ "\n"
+ "Creating a lot of cgroups at the same time might stall all worker\n"
+ "threads with kmem cache creation works, because kmem cache creation is\n"
+ "done with the slab_mutex held. The problem was amplified by commits\n"
+ "801faf0db894 (\"mm/slab: lockless decision to grow cache\") in case of\n"
+ "SLAB and 81ae6d03952c (\"mm/slub.c: replace kick_all_cpus_sync() with\n"
+ "synchronize_sched() in kmem_cache_shrink()\") in case of SLUB, which\n"
+ "increased the maximal time the slab_mutex can be held.\n"
+ "\n"
+ "To prevent that from happening, let's use a special ordered single\n"
+ "threaded workqueue for kmem cache creation. This shouldn't introduce any\n"
+ "functional changes regarding how kmem caches are created, as the work\n"
+ "function holds the global slab_mutex during its whole runtime anyway,\n"
+ "making it impossible to run more than one work at a time. By using a\n"
+ "single threaded workqueue, we just avoid creating a thread per each\n"
+ "work. Ordering is required to avoid a situation when a cgroup's work is\n"
+ "put off indefinitely because there are other cgroups to serve, in other\n"
+ "words to guarantee fairness.\n"
+ "\n"
+ "Link: https://bugzilla.kernel.org/show_bug.cgi?id=172981\n"
+ "Signed-off-by: Vladimir Davydov <vdavydov.dev@gmail.com>\n"
+ "Reported-by: Doug Smythies <dsmythies@telus.net>\n"
+ "Cc: Christoph Lameter <cl@linux.com>\n"
+ "Cc: David Rientjes <rientjes@google.com>\n"
+ "Cc: Johannes Weiner <hannes@cmpxchg.org>\n"
+ "Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\n"
+ "Cc: Michal Hocko <mhocko@kernel.org>\n"
+ "Cc: Pekka Enberg <penberg@kernel.org>\n"
+ "\n"
+ "diff --git a/mm/memcontrol.c b/mm/memcontrol.c\n"
+ "index 4be518d4e68a..8d753d87ca37 100644\n"
+ "--- a/mm/memcontrol.c\n"
+ "+++ b/mm/memcontrol.c\n"
+ "@@ -2175,6 +2175,8 @@ struct memcg_kmem_cache_create_work {\n"
+ " \tstruct work_struct work;\n"
+ " };\n"
+ " \n"
+ "+static struct workqueue_struct *memcg_kmem_cache_create_wq;\n"
+ "+\n"
+ " static void memcg_kmem_cache_create_func(struct work_struct *w)\n"
+ " {\n"
+ " \tstruct memcg_kmem_cache_create_work *cw =\n"
+ "@@ -2206,7 +2208,7 @@ static void __memcg_schedule_kmem_cache_create(struct mem_cgroup *memcg,\n"
+ " \tcw->cachep = cachep;\n"
+ " \tINIT_WORK(&cw->work, memcg_kmem_cache_create_func);\n"
+ " \n"
+ "-\tschedule_work(&cw->work);\n"
+ "+\tqueue_work(memcg_kmem_cache_create_wq, &cw->work);\n"
+ " }\n"
+ " \n"
+ " static void memcg_schedule_kmem_cache_create(struct mem_cgroup *memcg,\n"
+ "@@ -5794,6 +5796,17 @@ static int __init mem_cgroup_init(void)\n"
+ " {\n"
+ " \tint cpu, node;\n"
+ " \n"
+ "+#ifndef CONFIG_SLOB\n"
+ "+\t/*\n"
+ "+\t * Kmem cache creation is mostly done with the slab_mutex held,\n"
+ "+\t * so use a special workqueue to avoid stalling all worker\n"
+ "+\t * threads in case lots of cgroups are created simultaneously.\n"
+ "+\t */\n"
+ "+\tmemcg_kmem_cache_create_wq =\n"
+ "+\t\talloc_ordered_workqueue(\"memcg_kmem_cache_create\", 0);\n"
+ "+\tBUG_ON(!memcg_kmem_cache_create_wq);\n"
+ "+#endif\n"
+ "+\n"
+ " \thotcpu_notifier(memcg_cpu_hotplug_callback, 0);\n"
+ " \n"
+ " \tfor_each_possible_cpu(cpu)"
 
-8c035af9453efd66a15e88e25e6b36b9e2dcda6a90bfa2a1ef88519cec1e8d4b
+5cfefbeda560426abe9813bdcb27abbd09e76f8db089446b7a71063e29101b46

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.