aboutsummaryrefslogtreecommitdiffstats
path: root/etc/zfs
diff options
context:
space:
mode:
authorMatthew Ahrens <[email protected]>2020-02-13 11:23:02 -0800
committerGitHub <[email protected]>2020-02-13 11:23:02 -0800
commit2adc6b35aebc722d83329f0e340833263c6415aa (patch)
tree2ea41f78abee2bf088434f7915192f6914d6b720 /etc/zfs
parent465e4e795ee3cbdc5de862b26d81b2f1116733df (diff)
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 <[email protected]> Reviewed-by: Pavel Zakharov <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: George Wilson <[email protected]> Signed-off-by: Matthew Ahrens <[email protected]> Closes #9989
Diffstat (limited to 'etc/zfs')
0 files changed, 0 insertions, 0 deletions