From: Peter Zijlstra <peterz@infradead.org>
To: Pan Deng <pan.deng@intel.com>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
tianyou.li@intel.com, tim.c.chen@linux.intel.com,
yu.c.chen@intel.com
Subject: Re: [PATCH v2 4/4] sched/rt: Split cpupri_vec->cpumask to per NUMA node to reduce contention
Date: Fri, 20 Mar 2026 13:40:03 +0100 [thread overview]
Message-ID: <20260320124003.GU3738786@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <a3207ebf537bbe5605ff5454f63b5604d83a04a0.1753076363.git.pan.deng@intel.com>
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.
But somehow I doubt this is it.
I would suggest building a radix tree like structure based on ACPIID
-- which is inherently suitable for this given that is exactly how
CPUID-0b/1f are specified.
This of course makes it very much x86 specific, but perhaps other
architectures can provide similarly structured id spaces suitable for
this.
If you make it so that it reduces to a single large level (equivalent to
the normal bitmaps) when no intermediate masks are specific, it should
work for all, and then architectures can opt-in by providing a suitable
id space and masks.
next prev parent reply other threads:[~2026-03-20 12:40 UTC|newest]
Thread overview: 41+ 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 [this message]
2026-03-23 18:45 ` Tim Chen
2026-03-24 12:00 ` Peter Zijlstra
2026-03-31 5:37 ` Chen, Yu C
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-04-08 9:25 ` 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=20260320124003.GU3738786@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pan.deng@intel.com \
--cc=tianyou.li@intel.com \
--cc=tim.c.chen@linux.intel.com \
--cc=yu.c.chen@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