From: "Chen, Yu C" <yu.c.chen@intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
Tim Chen <tim.c.chen@linux.intel.com>
Cc: Pan Deng <pan.deng@intel.com>, <mingo@kernel.org>,
<linux-kernel@vger.kernel.org>, <tianyou.li@intel.com>,
<kprateek.nayak@amd.com>
Subject: Re: [PATCH v2 4/4] sched/rt: Split cpupri_vec->cpumask to per NUMA node to reduce contention
Date: Tue, 31 Mar 2026 13:37:39 +0800 [thread overview]
Message-ID: <138c3f9d-309f-41e6-aa72-a3f6bd713bf0@intel.com> (raw)
In-Reply-To: <20260324120008.GB3738010@noisy.programming.kicks-ass.net>
On 3/24/2026 8:00 PM, Peter Zijlstra wrote:
> On Mon, Mar 23, 2026 at 11:45:01AM -0700, Tim Chen wrote:
>> On Fri, 2026-03-20 at 13:40 +0100, Peter Zijlstra wrote:
>>> On Mon, Jul 21, 2025 at 02:10:26PM +0800, Pan Deng wrote:
>>>
>>>> This change splits `cpupri_vec->cpumask` into per-NUMA-node data to
>>>> mitigate false sharing.
>>>
>>> So I really do think we need something here. We're running into the
>>> whole cpumask contention thing on a semi regular basis.
>>>
[ ... ]
> +
> +unsigned int sbm_find_next_bit(struct sbm *sbm, int start)
> +{
> + struct sbm_leaf *leaf = (void *)sbm;
> + struct sbm_root *root = (void *)sbm;
> + int nr = start >> arch_sbm_shift;
> + int bit = start & arch_sbm_mask;
> + unsigned long tmp, mask = (~0UL) << bit;
> + if (sbm->type == st_root) {
> + for (; nr < arch_sbm_leafs; nr++, mask = ~0UL) {
> + leaf = root->leafs[nr];
> + tmp = leaf->bitmap & mask;
> + if (!tmp)
> + continue;
I suppose this should be
if (tmp)
break;
otherwise
[ 40.071616] watchdog: BUG: soft lockup - CPU#0 stuck for 30s!
[swapper/0:0]
[ 40.071616] Modules linked in:
[ 40.071616] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
7.0.0-rc5-sbm-+ #16 PREEMPT(full)
[ 40.071616] RIP: 0010:sbm_find_next_bit+0x2a/0xa0
> + }
> + } else {
> + tmp = leaf->bitmap & mask;
> + }
> + if (!tmp)
> + return -1;
> + return (nr << arch_sbm_shift) | __ffs(tmp);
> +}
update of the test:
With above change, I did a simple hackbench test on
a system with multiple LLCs within 1 node, so the benefit
is significant(+12%~+30%) when system is under-loaded, while
some regression when overloaded(-10%)(need to figure out)
thanks,
Chenyu
next prev parent reply other threads:[~2026-03-31 5:38 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-21 6:10 [PATCH v2 0/4] sched/rt: mitigate root_domain cache line contention Pan Deng
2025-07-21 6:10 ` [PATCH v2 1/4] sched/rt: Optimize cpupri_vec layout to mitigate " Pan Deng
2026-03-20 10:09 ` Peter Zijlstra
2026-03-24 9:36 ` Deng, Pan
2026-03-24 12:11 ` Peter Zijlstra
2026-03-27 10:17 ` Deng, Pan
2026-04-02 10:37 ` Deng, Pan
2026-04-02 10:43 ` Peter Zijlstra
2026-04-08 10:16 ` Chen, Yu C
2026-04-09 11:47 ` Deng, Pan
2025-07-21 6:10 ` [PATCH v2 2/4] sched/rt: Restructure root_domain to reduce cacheline contention Pan Deng
2026-03-20 10:18 ` Peter Zijlstra
2025-07-21 6:10 ` [PATCH v2 3/4] sched/rt: Split root_domain->rto_count to per-NUMA-node counters Pan Deng
2026-03-20 10:24 ` Peter Zijlstra
2026-03-23 18:09 ` Tim Chen
2026-03-24 12:16 ` Peter Zijlstra
2026-03-24 22:40 ` Tim Chen
2025-07-21 6:10 ` [PATCH v2 4/4] sched/rt: Split cpupri_vec->cpumask to per NUMA node to reduce contention Pan Deng
2026-03-20 12:40 ` Peter Zijlstra
2026-03-23 18:45 ` Tim Chen
2026-03-24 12:00 ` Peter Zijlstra
2026-03-31 5:37 ` Chen, Yu C [this message]
2026-03-31 10:19 ` K Prateek Nayak
2026-04-02 3:15 ` Chen, Yu C
2026-04-02 4:41 ` K Prateek Nayak
2026-04-02 10:55 ` Peter Zijlstra
2026-04-02 11:06 ` K Prateek Nayak
2026-04-03 5:46 ` Chen, Yu C
2026-04-03 8:13 ` K Prateek Nayak
2026-04-07 20:35 ` Tim Chen
2026-04-08 3:06 ` K Prateek Nayak
2026-04-08 11:35 ` Chen, Yu C
2026-04-08 15:52 ` K Prateek Nayak
2026-04-09 5:17 ` K Prateek Nayak
2026-04-09 23:09 ` Tim Chen
2026-04-10 5:51 ` Chen, Yu C
2026-04-10 6:02 ` K Prateek Nayak
2026-05-10 15:59 ` [PATCH v2 1/4] sched/rt: Optimize cpupri_vec layout to mitigate cache line contention Chen Yu
2026-05-10 15:59 ` [PATCH 1/3] x86/sbm: Fix domain shift calculation and sbm_find_next_bit() Chen Yu
2026-05-10 15:59 ` [PATCH 2/3] lib/sbm: Use dynamically sized bitmap in sbm_leaf Chen Yu
2026-05-10 15:59 ` [PATCH 3/3] x86/sbm: Derive leaf granularity from LLC cacheinfo instead of topology domain Chen Yu
2026-05-11 7:48 ` K Prateek Nayak
2026-05-12 9:29 ` Chen, Yu C
2026-04-08 9:25 ` [PATCH v2 4/4] sched/rt: Split cpupri_vec->cpumask to per NUMA node to reduce contention Chen, Yu C
2026-04-08 16:47 ` Tim Chen
2026-03-20 9:59 ` [PATCH v2 0/4] sched/rt: mitigate root_domain cache line contention Peter Zijlstra
2026-03-20 12:50 ` Peter Zijlstra
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=138c3f9d-309f-41e6-aa72-a3f6bd713bf0@intel.com \
--to=yu.c.chen@intel.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pan.deng@intel.com \
--cc=peterz@infradead.org \
--cc=tianyou.li@intel.com \
--cc=tim.c.chen@linux.intel.com \
/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
Powered by JetHome