[v3,0/2] slub: introduce count_partial_free_approx()

Message

Jianfeng Wang April 19, 2024, 5:56 p.m. UTC

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 slubs, their partial lists
can be extremely long. Currently, count_partial() traverses a partial
list to get the exact count of objects. This process may take a long
time, during which slab allocations are blocked and IRQs are disabled.
In production, even NMI watchdog can be triggered due to this matter.

The proposed fix is to limit the number of slabs to scan and output an
approximated count for a long partial list. The v1 patch counts N slabs
from the list's head and then uses it to estimate the total object
count in the list. As suggested by Vlastimil, the v2 patch uses an
alternative, i.e., counting N/2 from the list's head and tail, produces
a more accurate approximation after the partial list is sorted by
kmem_cache_shrink(). In this version, the implementation is moved to a
new function count_partial_free_approx(). count_partial() is still used
in sysfs for users who still want the exact object count.

---
Changes since v2 [2]
 - Introduce count_partial_free_approx() and keep count_partial()
 - Use count_partial_free_approx() in get_slabinfo() and slab_out_of_memory()

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/[e-mail]/
[2] https://lore.kernel.org/linux-mm/[e-mail]/

Thanks,
--Jianfeng

Jianfeng Wang (2):
  slub: introduce count_partial_free_approx()
  slub: use count_partial_free_approx() in slab_out_of_memory()

 mm/slub.c | 41 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 39 insertions(+), 2 deletions(-)

Comments

Vlastimil Babka April 22, 2024, 7:56 a.m. UTC | #1

On 4/19/24 7:56 PM, Jianfeng Wang wrote:
> 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 slubs, their partial lists
> can be extremely long. Currently, count_partial() traverses a partial
> list to get the exact count of objects. This process may take a long
> time, during which slab allocations are blocked and IRQs are disabled.
> In production, even NMI watchdog can be triggered due to this matter.
> 
> The proposed fix is to limit the number of slabs to scan and output an
> approximated count for a long partial list. The v1 patch counts N slabs
> from the list's head and then uses it to estimate the total object
> count in the list. As suggested by Vlastimil, the v2 patch uses an
> alternative, i.e., counting N/2 from the list's head and tail, produces
> a more accurate approximation after the partial list is sorted by
> kmem_cache_shrink(). In this version, the implementation is moved to a
> new function count_partial_free_approx(). count_partial() is still used
> in sysfs for users who still want the exact object count.

Added to slab/for-next, thanks!

> 
> ---
> Changes since v2 [2]
>  - Introduce count_partial_free_approx() and keep count_partial()
>  - Use count_partial_free_approx() in get_slabinfo() and slab_out_of_memory()
> 
> 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/[e-mail]/
> [2] https://lore.kernel.org/linux-mm/[e-mail]/
> 
> Thanks,
> --Jianfeng
> 
> Jianfeng Wang (2):
>   slub: introduce count_partial_free_approx()
>   slub: use count_partial_free_approx() in slab_out_of_memory()
> 
>  mm/slub.c | 41 +++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 39 insertions(+), 2 deletions(-)
>