From: "Christoph Lameter (Ampere)" <cl@linux.com>
To: Jianfeng Wang <jianfeng.w.wang@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Chengming Zhou <chengming.zhou@linux.dev>,
David Rientjes <rientjes@google.com>,
penberg@kernel.org, iamjoonsoo.kim@lge.com,
akpm@linux-foundation.org, roman.gushchin@linux.dev,
42.hyeyoo@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] slub: avoid scanning all partial slabs in get_slabinfo()
Date: Thu, 14 Mar 2024 16:45:04 -0700 (PDT) [thread overview]
Message-ID: <1e01092b-140d-2bab-aeba-321a74a194ee@linux.com> (raw)
In-Reply-To: <9578474c-2e46-4d3e-9a2f-1eaeb9bfabbc@oracle.com>
On Wed, 13 Mar 2024, Jianfeng Wang wrote:
> I am not sure that the RCU change will solve the lockup problem.
> The reason is that iterating a super long list of partial slabs is a problem by itself, e.g., on a
> non-preemptive kernel, then count_partial() can be stuck in the loop for a while, which can cause problems.
>
> Also, even if we check the list ownership for slabs, we may spend too much time in the loop if no updater shows up,
> or fail and re-do many times the loop if several updates happen. The latter can exacerbate this lockup issue. So,
> in the end, reading /proc/slabinfo can take a super long time just for a counter that may be changing all the time.
Well we could also cache the values somehow to avoid the scans? invalidate
the counter if something significant happens.
> Thus, I prefer the "guesstimate" approach, even if the number is inaccurate or biased. Let me know if this makes sense.
Come up with a patch and then lets see how well it works.
next prev parent reply other threads:[~2024-03-14 23:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 21:14 [PATCH] slub: avoid scanning all partial slabs in get_slabinfo() Jianfeng Wang
2024-02-18 19:25 ` David Rientjes
2024-02-19 8:30 ` Vlastimil Babka
2024-02-19 9:29 ` Chengming Zhou
2024-02-19 10:17 ` Vlastimil Babka
2024-02-22 13:20 ` Chengming Zhou
2024-02-23 3:02 ` Christoph Lameter (Ampere)
2024-02-23 3:36 ` Chengming Zhou
2024-02-23 3:50 ` Christoph Lameter (Ampere)
2024-02-23 5:00 ` Chengming Zhou
2024-02-23 9:24 ` Vlastimil Babka
2024-02-23 9:37 ` Chengming Zhou
2024-02-23 9:46 ` Chengming Zhou
2024-02-23 9:51 ` Vlastimil Babka
2024-02-26 17:38 ` Christoph Lameter (Ampere)
2024-02-27 9:30 ` Chengming Zhou
2024-02-27 22:55 ` Christoph Lameter (Ampere)
2024-02-28 9:51 ` Chengming Zhou
2024-03-14 0:38 ` Jianfeng Wang
2024-03-14 23:45 ` Christoph Lameter (Ampere) [this message]
2024-02-23 7:36 ` Jianfeng Wang
2024-02-23 9:17 ` Vlastimil Babka
2024-02-20 18:41 ` 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=1e01092b-140d-2bab-aeba-321a74a194ee@linux.com \
--to=cl@linux.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=iamjoonsoo.kim@lge.com \
--cc=jianfeng.w.wang@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--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).