]> git.proxmox.com Git - mirror_zfs.git/commit - module/os/linux/spl/spl-kmem-cache.c
Missed wakeup when growing kmem cache
authorMatthew Ahrens <mahrens@delphix.com>
Thu, 13 Feb 2020 19:23:02 +0000 (11:23 -0800)
committerGitHub <noreply@github.com>
Thu, 13 Feb 2020 19:23:02 +0000 (11:23 -0800)
commit2adc6b35aebc722d83329f0e340833263c6415aa
tree2ea41f78abee2bf088434f7915192f6914d6b720
parent465e4e795ee3cbdc5de862b26d81b2f1116733df
Missed wakeup when growing kmem cache

When growing the size of a (VMEM or KVMEM) kmem cache, spl_cache_grow()
always does taskq_dispatch(spl_cache_grow_work), and then waits for the
KMC_BIT_GROWING to be cleared by the taskq thread.

The taskq thread (spl_cache_grow_work()) does:
1. allocate new slab and add to list
2. wake_up_all(skc_waitq)
3. clear_bit(KMC_BIT_GROWING)

Therefore, the waiting thread can wake up before GROWING has been
cleared.  It will see that the growing has not yet completed, and go
back to sleep until it hits the 100ms timeout.

This can have an extreme performance impact on workloads that alloc/free
more than fits in the (statically-sized) magazines.  These workloads
allocate and free slabs with high frequency.

The problem can be observed with `funclatency spl_cache_grow`, which on
some workloads shows that 99.5% of the time it takes <64us to allocate
slabs, but we spend ~70% of our time in outliers, waiting for the 100ms
timeout.

The fix is to do `clear_bit(KMC_BIT_GROWING)` before
`wake_up_all(skc_waitq)`.

A future investigation should evaluate if we still actually need to
taskq_dispatch() at all, and if so on which kernel versions.

Reviewed-by: Paul Dagnelie <pcd@delphix.com>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: George Wilson <gwilson@delphix.com>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #9989
module/os/linux/spl/spl-kmem-cache.c