From: "Christoph Lameter (Ampere)" <cl@linux.com>
To: Jianfeng Wang <jianfeng.w.wang@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com,
akpm@linux-foundation.org, vbabka@suse.cz,
junxiao.bi@oracle.com
Subject: Re: [PATCH] slub: limit number of slabs to scan in count_partial()
Date: Thu, 11 Apr 2024 10:02:25 -0700 (PDT) [thread overview]
Message-ID: <e0222219-eb2d-5e1e-81e1-548eeb5f73e0@linux.com> (raw)
In-Reply-To: <20240411164023.99368-1-jianfeng.w.wang@oracle.com>
On Thu, 11 Apr 2024, Jianfeng Wang wrote:
> So, the fix is to limit the number of slabs to scan in
> count_partial(), and output an approximated result if the list is too
> long. Default to 10000 which should be enough for most sane cases.
That is a creative approach. The problem though is that objects on the
partial lists are kind of sorted. The partial slabs with only a few
objects available are at the start of the list so that allocations cause
them to be removed from the partial list fast. Full slabs do not need to
be tracked on any list.
The partial slabs with few objects are put at the end of the partial list
in the hope that the few objects remaining will also be freed which would
allow the freeing of the slab folio.
So the object density may be higher at the beginning of the list.
kmem_cache_shrink() will explicitly sort the partial lists to put the
partial pages in that order.
Can you run some tests showing the difference between the estimation and
the real count?
next prev parent reply other threads:[~2024-04-11 17:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 16:40 [PATCH] slub: limit number of slabs to scan in count_partial() Jianfeng Wang
2024-04-11 17:02 ` Christoph Lameter (Ampere) [this message]
2024-04-12 7:48 ` Vlastimil Babka
2024-04-12 17:29 ` [External] : " Jianfeng Wang
2024-04-12 18:16 ` Christoph Lameter (Ampere)
2024-04-12 18:32 ` Jianfeng Wang
2024-04-12 20:20 ` [External] : " Vlastimil Babka
2024-04-12 20:44 ` Jianfeng Wang
2024-04-13 1:17 ` Jianfeng Wang
2024-04-15 7:35 ` Vlastimil Babka
2024-04-16 18:58 ` Jianfeng Wang
2024-04-16 20:14 ` Vlastimil Babka
2024-04-15 16:20 ` Christoph Lameter (Ampere)
2024-04-13 4:43 ` [External] : " Matthew Wilcox
2024-04-12 7:41 ` Vlastimil Babka
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=e0222219-eb2d-5e1e-81e1-548eeb5f73e0@linux.com \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jianfeng.w.wang@oracle.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