Re: [PATCH 1/2] mm: memcontrol: use special workqueue for creating per-memcg caches
From: Vladimir Davydov <hidden>
Date: 2016-10-03 12:35:19
Also in:
lkml
On Mon, Oct 03, 2016 at 02:06:42PM +0200, Michal Hocko wrote:
On Sat 01-10-16 16:56:47, Vladimir Davydov wrote:quoted
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. To prevent that from happening, let's use a special workqueue for kmem cache creation with max in-flight work items equal to 1. Link: https://bugzilla.kernel.org/show_bug.cgi?id=172981This looks like a regression but I am not really sure I understand what has caused it. We had the WQ based cache creation since kmem was introduced more or less. So is it 801faf0db894 ("mm/slab: lockless decision to grow cache") which was pointed by bisection that changed the timing resp. relaxed the cache creation to the point that would allow this runaway?
It is in case of SLAB. For SLUB the issue was caused by commit
81ae6d03952c ("mm/slub.c: replace kick_all_cpus_sync() with
synchronize_sched() in kmem_cache_shrink()").
This would be really useful for the stable backport consideration. Also, if I understand the fix correctly, now we do limit the number of workers to 1 thread. Is this really what we want? Wouldn't it be possible that few memcgs could starve others fromm having their cache created? What would be the result, missed charges?
Now kmem caches are created in FIFO order, i.e. if one memcg called kmem_cache_alloc on a non-existent cache before another, it will be served first. Since the number of caches that can be created by a single memcg is obviously limited, I don't see any possibility of starvation. Actually, this patch doesn't introduce any functional changes regarding the order in which kmem caches are created, as the work function holds the global slab_mutex during its whole runtime anyway. We only avoid creating a thread per each work by making the queue single-threaded. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>