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 [thread overview]
Message-ID: <20240417185938.5237-1-jianfeng.w.wang@oracle.com> (raw)
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
next reply other threads:[~2024-04-17 18:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 18:59 Jianfeng Wang [this message]
2024-04-17 18:59 ` [PATCH v2 1/1] slub: limit number of slabs to scan in count_partial() Jianfeng Wang
2024-04-18 10:01 ` Vlastimil Babka
2024-04-18 22:44 ` Jianfeng Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240417185938.5237-1-jianfeng.w.wang@oracle.com \
--to=jianfeng.w.wang@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=junxiao.bi@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).