This patch fixes a known issue in get_slabinfo() which relies on count_partial() to get the exact count of free objects in a kmem_cache_node's partial list. For some slub caches, their per-node partial list can be extremely long. The current version of count_partial() traverses the partial list to get the exact count of objects while holding the kmem_cache_node's spinlock. This process may take a long time, during which slab allocations are blocked and IRQs are disabled. In production workloads, even NMI watchdog can be triggered due to this matter. Moreover, getting the exact count of objects may not be useful as well: the count may change right after the spinlock is released and re-captured by others. The proposed fix is to limit the number of slabs to scan, and output an approximated object count for a long partial list. The v1 patch counts N slabs from the list's head and then uses it to approximate the total object count in the list. As suggested by Vlastimil, an alternative method, i.e., counting N/2 from both the list's head and tail, produces a more accurate approximation after the partial list is sorted by kmem_cache_shrink(). --- Changes since v1 [1] - Update the approximation method by counting from the list's head and tail - Cap the approximation by the total object count - Update the commit message to add benchmark results and explain the choice [1] https://lore.kernel.org/linux-mm/20240411164023.99368-1-jianfeng.w.wang@xxxxxxxxxx/ Thanks, --Jianfeng Jianfeng Wang (1): slub: limit number of slabs to scan in count_partial() mm/slub.c | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) -- 2.42.1
