Re: [PATCH v2 4/4] sched/rt: Split cpupri_vec->cpumask to per NUMA node to reduce contention
From: Tim Chen
Date: Mon Mar 23 2026 - 14:55:31 EST
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.
>
> 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.
>
Are you thinking about replacing cpumask in cpupri_vec with something like xarray?
And a question on using ACPIID for the CPU as index instead of CPUID.
Is it because you want to even out access in the tree?
Tim
> 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.