Thread (63 messages) 63 messages, 7 authors, 2021-07-29

Re: [RFC v2 29/34] mm: slub: Move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context

From: Cyrill Gorcunov <hidden>
Date: 2021-06-10 08:37:44
Also in: lkml

On Thu, Jun 10, 2021 at 10:32:14AM +0200, Vlastimil Babka wrote:
quoted
quoted
 static void flush_all(struct kmem_cache *s)
 {
-	on_each_cpu_cond(has_cpu_slab, flush_cpu_slab, s, 1);
+	struct slub_flush_work *sfw;
+	unsigned int cpu;
+
+	cpus_read_lock();
+	mutex_lock(&flush_lock);
+
Hi, Vlastimil! Could you please point why do you lock cpus first and
mutex only after? Why not mutex_lock + cpus_read_lock instead?
Good question! I must admit I didn't think about it much and just followed the
order that was in the original Sebastian's patch [1]
But there was a good reason for this order as some paths via
__kmem_cache_shutdown() and __kmem_cache_shrink() were alreadu called under
cpus_read_lock. Meanwhile mainline (me, actually) removed those, so now it
doesn't seem to be a need to keep this order anymore and we could switch it.
I bet we should switch :) But we can do that on top later, once series is
settled down and merged.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help