Received-SPF: pass (google.com: domain of linux-kernel+bounces-149096-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Jianfeng Wang <jianfeng.w.wang@oracle.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: akpm@linux-foundation.org, cl@linux.com, vbabka@suse.cz,
        penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com,
        junxiao.bi@oracle.com
Subject: [PATCH v2 0/1] slub: limit number of slabs to scan in count_partial()
Date: Wed, 17 Apr 2024 11:59:37 -0700
Message-ID: <20240417185938.5237-1-jianfeng.w.wang@oracle.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

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@oracle.com/

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