Conversation
|
There may also be a need to backport the following upstream patch series as a fix: |
aubreyli
force-pushed
the
intel-numa-sched-domain-6.6
branch
2 times, most recently
from
April 14, 2026 14:56
8b2dedc to
0c005ab
Compare
Contributor
Author
|
This branch is clone from ve-6.6 branch at "8d21376710dc bytedance: Revert "perf arm-spe: Extend branch operations"", 0001-powerpc-smp-Enable-Asym-packing-for-cores-on-shared-.patch Tested on 2-socket GNR SNC3 machine, "cat /proc/schedstat" shows correct sched domain: |
aubreyli
force-pushed
the
intel-numa-sched-domain-6.6
branch
from
September 17, 2026 13:40
0c005ab to
09884a3
Compare
Contributor
Author
|
Retested on GNR machine with SNC-3,
|
commit aa80c63 upstream. If there are shared processor LPARs, underlying Hypervisor can have more virtual cores to handle than actual physical cores. Starting with Power 9, a big core (aka SMT8 core) has 2 nearly independent thread groups. On a shared processors LPARs, it helps to pack threads to lesser number of cores so that the overall system performance and utilization improves. PowerVM schedules at a big core level. Hence packing to fewer cores helps. Since each thread-group is independent, running threads on both the thread-groups of a SMT8 core, should have a minimal adverse impact in non over provisioned scenarios. These changes in this patchset will not affect in the over provisioned scenario. If there are more threads than SMT domains, then asym_packing will not kick-in For example: Lets says there are two 8-core Shared LPARs that are actually sharing a 8 Core shared physical pool, each running 8 threads each. Then Consolidating 8 threads to 4 cores on each LPAR would help them to perform better. This is because each of the LPAR will get 100% time to run applications and there will no switching required by the Hypervisor. To achieve this, enable SD_ASYM_PACKING flag at CACHE, MC and DIE level when the system is running in shared processor mode and has big cores. Intel-SIG: commit aa80c63 powerpc/smp: Enable Asym packing for cores on shared processor. Backport x86/topo: SNC Divination dependency Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231214180720.310852-2-srikar@linux.vnet.ibm.com [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 0e1c198 upstream. Like L2-cache info, coregroup information which is used to determine MC sched domains is only present on dedicated LPARs. i.e PowerVM doesn't export coregroup information for shared processor LPARs. Hence disable creating MC domains on shared LPAR Systems. Intel-SIG: commit 0e1c198 powerpc/smp: Disable MC domain for shared processor. Backport x86/topo: SNC Divination dependency Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231214180720.310852-3-srikar@linux.vnet.ibm.com [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit fd535a8 upstream. There are some variables that are only updated at boot time. So add __ro_after_init attribute to such variables Intel-SIG: commit fd535a8 powerpc/smp: Add __ro_after_init attribute. Backport x86/topo: SNC Divination dependency Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231214180720.310852-4-srikar@linux.vnet.ibm.com [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 0e93f1c upstream. PowerVM Hypervisor will schedule at a core granularity. However each core can have more than one thread_groups. For better utilization in case of a shared processor, its preferable for the scheduler to pack to the lowest core. However there is no benefit of moving a thread between two thread groups of the same core. Intel-SIG: commit 0e93f1c powerpc/smp: Avoid asym packing within thread_group of a core. Backport x86/topo: SNC Divination dependency Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231214180720.310852-5-srikar@linux.vnet.ibm.com [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit c469757 upstream. Currently there are four Powerpc specific sched topologies. These are all statically defined. However not all these topologies are used by all Powerpc systems. To avoid unnecessary degenerations by the scheduler, masks and flags are compared. However if the sched topologies are build dynamically then the code is simpler and there are greater chances of avoiding degenerations. Note: Even X86 builds its sched topologies dynamically and proposed changes are very similar to the way X86 is building its topologies. Intel-SIG: commit c469757 powerpc/smp: Dynamically build Powerpc topology. Backport x86/topo: SNC Divination dependency Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231214180720.310852-6-srikar@linux.vnet.ibm.com [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit d12a828 upstream. Add support for autopointers for bitmaps allocated with bitmap_alloc() et al. Intel-SIG: commit d12a828 Define a cleanup function for bitmaps. Backport fix NUMA sched domain build errors for GNR and CWF. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Yury Norov <yury.norov@gmail.com> Link: https://lore.kernel.org/r/20240122124243.44002-2-brgl@bgdev.pl [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 06f2c90885e92992d1ce55d3f35b65b44d5ecc25 upstream. Allow architecture specific sched domain NUMA distances that are modified from actual NUMA node distances for the purpose of building NUMA sched domains. Keep actual NUMA distances separately if modified distances are used for building sched domains. Such distances are still needed as NUMA balancing benefits from finding the NUMA nodes that are actually closer to a task numa_group. Consolidate the recording of unique NUMA distances in an array to sched_record_numa_dist() so the function can be reused to record NUMA distances when the NUMA distance metric is changed. No functional change and additional distance array allocated if there're no arch specific NUMA distances being defined. Intel-SIG: commit 06f2c90885e9 Create architecture specific sched domain distances. Backport fix NUMA sched domain build errors for GNR and CWF. Co-developed-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Chen Yu <yu.c.chen@intel.com> [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 4d6dd05d07d00bc3bd91183dab4d75caa8018db9 upstream.
It is possible for Granite Rapids (GNR) and Clearwater Forest
(CWF) to have up to 3 dies per package. When sub-numa cluster (SNC-3)
is enabled, each die will become a separate NUMA node in the package
with different distances between dies within the same package.
For example, on GNR, we see the following numa distances for a 2 socket
system with 3 dies per socket:
package 1 package2
----------------
| |
--------- ---------
| 0 | | 3 |
--------- ---------
| |
--------- ---------
| 1 | | 4 |
--------- ---------
| |
--------- ---------
| 2 | | 5 |
--------- ---------
| |
----------------
node distances:
node 0 1 2 3 4 5
0: 10 15 17 21 28 26
1: 15 10 15 23 26 23
2: 17 15 10 26 23 21
3: 21 28 26 10 15 17
4: 23 26 23 15 10 15
5: 26 23 21 17 15 10
The node distances above led to 2 problems:
1. Asymmetric routes taken between nodes in different packages led to
asymmetric scheduler domain perspective depending on which node you
are on. Current scheduler code failed to build domains properly with
asymmetric distances.
2. Multiple remote distances to respective tiles on remote package create
too many levels of domain hierarchies grouping different nodes between
remote packages.
For example, the above GNR topology lead to NUMA domains below:
Sched domains from the perspective of a CPU in node 0, where the number
in bracket represent node number.
NUMA-level 1 [0,1] [2]
NUMA-level 2 [0,1,2] [3]
NUMA-level 3 [0,1,2,3] [5]
NUMA-level 4 [0,1,2,3,5] [4]
Sched domains from the perspective of a CPU in node 4
NUMA-level 1 [4] [3,5]
NUMA-level 2 [3,4,5] [0,2]
NUMA-level 3 [0,2,3,4,5] [1]
Scheduler group peers for load balancing from the perspective of CPU 0
and 4 are different. Improper task could be chosen for load balancing
between groups such as [0,2,3,4,5] [1]. Ideally you should choose nodes
in 0 or 2 that are in same package as node 1 first. But instead tasks
in the remote package node 3, 4, 5 could be chosen with an equal chance
and could lead to excessive remote package migrations and imbalance of
load between packages. We should not group partial remote nodes and
local nodes together.
Simplify the remote distances for CWF and GNR for the purpose of
sched domains building, which maintains symmetry and leads to a more
reasonable load balance hierarchy.
The sched domains from the perspective of a CPU in node 0 NUMA-level 1
is now
NUMA-level 1 [0,1] [2]
NUMA-level 2 [0,1,2] [3,4,5]
The sched domains from the perspective of a CPU in node 4 NUMA-level 1
is now
NUMA-level 1 [4] [3,5]
NUMA-level 2 [3,4,5] [0,1,2]
We have the same balancing perspective from node 0 or node 4. Loads are
now balanced equally between packages.
Intel-SIG: commit 4d6dd05d07d0 Fix sched domain build error for GNR, CWF in SNC-3 mode.
Backport fix NUMA sched domain build errors for GNR and CWF.
Co-developed-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
Tested-by: Zhao Liu <zhao1.liu@intel.com>
[ Aubrey Li: amend commit log ]
Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 73cbcfe255f7edca915d978a7d1b0a11f2d62812 upstream.
A compile warning slipped through:
arch/x86/kernel/smpboot.c:548:5: warning: no previous prototype for function 'arch_sched_node_distance' [-Wmissing-prototypes]
Intel-SIG: commit 73cbcfe255f7 Fix build warning.
Backport fix NUMA sched domain build errors for GNR and CWF.
Fixes: 4d6dd05d07d0 ("sched/topology: Fix sched domain build error for GNR, CWF in SNC-3 mode")
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
[ Aubrey Li: amend commit log ]
Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 830a0d1 upstream. This per CPU log is becoming longer with more and more CPUs in system, which slows down the boot process due to the serializing nature of printk(). The value of this information is dubious and it can be retrieved by lscpu from user space if required.. Downgrade the printk() to pr_debug() so it is still accessible for debug purposes. [ tglx: Massaged changelog ] Intel-SIG: commit 830a0d1 Don't print out SRAT table information. Backport x86/topo: SNC Divination Signed-off-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20240806120823.17111-1-lirongqing@baidu.com [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 537e247879589f6bace747e3479e4abf42dbbbdc upstream. x86_*_flags() wrappers were introduced with commit d3d37d8 ("x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU") to add x86_sched_itmt_flags() in addition to the default domain flags for SMT and MC domain. commit 995998e ("x86/sched: Remove SD_ASYM_PACKING from the SMT domain flags") removed the ITMT flags for SMT domain but not the x86_smt_flags() wrappers which directly returns cpu_smt_flags(). Remove x86_smt_flags() and directly use cpu_smt_flags() to derive the flags for SMT domain. No functional changes intended. Intel-SIG: commit 537e24787958 Remove x86_smt_flags and use cpu_smt_flags directly. Backport x86/topo: SNC Divination dependency Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com> Link: https://lore.kernel.org/r/20241223043407.1611-5-kprateek.nayak@amd.com [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 1c055a0f5d3bafaca5d218bbb3e4e63d6307be45 upstream. /proc/schedstat file shows cpu and sched domain level scheduler statistics. It does not show domain name instead shows domain level. It will be very useful for tools like `perf sched stats`[1] to aggragate domain level stats if domain names are shown in /proc/schedstat. But sched domain name is guarded by CONFIG_SCHED_DEBUG. As per the discussion[2], move sched domain name out of CONFIG_SCHED_DEBUG. [1] https://lore.kernel.org/lkml/20241122084452.1064968-1-swapnil.sapkal@amd.com/ [2] https://lore.kernel.org/lkml/fcefeb4d-3acb-462d-9c9b-3df8d927e522@amd.com/ Intel-SIG: commit 1c055a0f5d3b Move sched domain name out of CONFIG_SCHED_DEBUG. Backport x86/topo: SNC Divination dependency Suggested-by: "Gautham R. Shenoy" <gautham.shenoy@amd.com> Signed-off-by: Swapnil Sapkal <swapnil.sapkal@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20241220063224.17767-5-swapnil.sapkal@amd.com [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit e075f4360931263f5ec006ea5dadc065e5e98eb8 upstream. Define a small SDTL_INIT(maskfn, flagsfn, name) macro and use it to build the sched_domain_topology_level array. Purely a cleanup; behaviour is unchanged. Intel-SIG: commit e075f4360931 introduce SDTL_INIT() helper to tidy sched topology setup. Backport x86/topo: SNC Divination Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://lore.kernel.org/r/20250710105715.66594-2-me@linux.beauty [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 992de2b02509bed68f693ea5a68b07cd586197b7 upstream. On x86 CONFIG_SCHED_SMT is default y if SMP is enabled, so let's simply drop CONFIG_SCHED_SMT. Intel-SIG: commit 992de2b02509 remove redundant CONFIG_SCHED_SMT. Backport x86/topo: SNC Divination Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://lore.kernel.org/r/20250710105715.66594-3-me@linux.beauty [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit fbc2010d92e595dc13d8048db2419f963c8cb25e upstream. The #ifdeffery and the initializers in build_sched_topology() are just disgusting. Statically initialize the domain levels in the topology array and let build_sched_topology() invalidate the package domain level when NUMA in package is available. Intel-SIG: commit fbc2010d92e5 moves x86_topology to static initialize and truncate. Backport x86/topo: SNC Divination Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://lore.kernel.org/r/20250710105715.66594-4-me@linux.beauty [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit f79c9aa446d638190578515afcd06d6c9d72da55 upstream. Currently, the SMT domain is added into sched_domain_topology by default. If cpu_attach_domain() finds that the CPU SMT domain’s cpumask_weight is just 1, it will destroy it. On a large machine, such as one with 512 cores, this results in 512 redundant domain attach/destroy operations. Avoid these unnecessary operations by simply checking cpu_smt_num_threads and skip SMT domain if the SMT domain is not enabled. Intel-SIG: commit f79c9aa446d6 avoid SMT domain attach/destroy if SMT is not enabled. Backport x86/topo: SNC Divination Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://lore.kernel.org/r/20250710105715.66594-5-me@linux.beauty [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 48084cc153a5b0fbf0aa98d47670d3be0b9f64d5 upstream. The topology setup code needs to know the total number of physical nodes enumerated in SRAT; however NUMA_EMU can cause the existing numa_nodes_parsed bitmap to be fictitious. Therefore, keep a copy of the bitmap specifically to retain the physical node count. Intel-SIG: commit 48084cc153a5 x86/numa: Store extra copy of numa_nodes_parsed. Backport x86/topo: SNC Divination Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ingo Molnar <mingo@kernel.org> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Tested-by: Kyle Meyer <kyle.meyer@hpe.com> Link: https://patch.msgid.link/20260303110059.889884023@infradead.org [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit ae6730ff42b3a13d94b405edeb5e40108b6d21b6 upstream. Use the MADT and SRAT table data to compute __num_nodes_per_package. Specifically, SRAT has already been parsed in x86_numa_init(), which is called before acpi_boot_init() which parses MADT. So both are available in topology_init_possible_cpus(). This number is useful to divinate the various Intel CoD/SNC and AMD NPS modes, since the platforms are failing to provide this otherwise. Doing it this way is independent of the number of online CPUs and other such shenanigans. Intel-SIG: commit ae6730ff42b3 x86/topo: Add topology_num_nodes_per_package(). Backport x86/topo: SNC Divination Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ingo Molnar <mingo@kernel.org> Tested-by: Tony Luck <tony.luck@intel.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Tested-by: Kyle Meyer <kyle.meyer@hpe.com> Link: https://patch.msgid.link/20260303110100.004091624@infradead.org [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 717b64d58cff6fb97f97be07e382ed7641167a56 upstream. .. with the brand spanking new topology_num_nodes_per_package(). Having the topology setup determine this value during MADT/SRAT parsing before SMP bringup avoids having to detect this situation when building the SMP topology masks. Intel-SIG: commit 717b64d58cff x86/topo: Replace x86_has_numa_in_package. Backport x86/topo: SNC Divination Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ingo Molnar <mingo@kernel.org> Tested-by: Tony Luck <tony.luck@intel.com> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> Tested-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Tested-by: Kyle Meyer <kyle.meyer@hpe.com> Link: https://patch.msgid.link/20260303110100.123701837@infradead.org [ Aubrey Li: amend commit log ] Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
commit 528d89a4707e5bfd86e30823c45dbb66877df900 upstream.
Per 4d6dd05d07d0 ("sched/topology: Fix sched domain build error for GNR, CWF in
SNC-3 mode"), the original crazy SNC-3 SLIT table was:
node distances:
node 0 1 2 3 4 5
0: 10 15 17 21 28 26
1: 15 10 15 23 26 23
2: 17 15 10 26 23 21
3: 21 28 26 10 15 17
4: 23 26 23 15 10 15
5: 26 23 21 17 15 10
And per:
https://lore.kernel.org/lkml/20250825075642.GQ3245006@noisy.programming.kicks-ass.net/
The suggestion was to average the off-trace clusters to restore sanity.
However, 4d6dd05d07d0 implements this under various assumptions:
- anything GNR/CWF with numa_in_package;
- there will never be more than 2 packages;
- the off-trace cluster will have distance >20
And then HPE shows up with a machine that matches the
Vendor-Family-Model checks but looks like this:
Here's an 8 socket (2 chassis) HPE system with SNC enabled:
node 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0: 10 12 16 16 16 16 18 18 40 40 40 40 40 40 40 40
1: 12 10 16 16 16 16 18 18 40 40 40 40 40 40 40 40
2: 16 16 10 12 18 18 16 16 40 40 40 40 40 40 40 40
3: 16 16 12 10 18 18 16 16 40 40 40 40 40 40 40 40
4: 16 16 18 18 10 12 16 16 40 40 40 40 40 40 40 40
5: 16 16 18 18 12 10 16 16 40 40 40 40 40 40 40 40
6: 18 18 16 16 16 16 10 12 40 40 40 40 40 40 40 40
7: 18 18 16 16 16 16 12 10 40 40 40 40 40 40 40 40
8: 40 40 40 40 40 40 40 40 10 12 16 16 16 16 18 18
9: 40 40 40 40 40 40 40 40 12 10 16 16 16 16 18 18
10: 40 40 40 40 40 40 40 40 16 16 10 12 18 18 16 16
11: 40 40 40 40 40 40 40 40 16 16 12 10 18 18 16 16
12: 40 40 40 40 40 40 40 40 16 16 18 18 10 12 16 16
13: 40 40 40 40 40 40 40 40 16 16 18 18 12 10 16 16
14: 40 40 40 40 40 40 40 40 18 18 16 16 16 16 10 12
15: 40 40 40 40 40 40 40 40 18 18 16 16 16 16 12 10
10 = Same chassis and socket
12 = Same chassis and socket (SNC)
16 = Same chassis and adjacent socket
18 = Same chassis and non-adjacent socket
40 = Different chassis
Turns out, the 'max 2 packages' thing is only relevant to the SNC-3 parts, the
smaller parts do 8 sockets (like usual). The above SLIT table is sane, but
violates the previous assumptions and trips a WARN.
Now that the topology code has a sensible measure of nodes-per-package, we can
use that to divinate the SNC mode at hand, and only fix up SNC-3 topologies.
There is a 'healthy' amount of paranoia code validating the assumptions on the
SLIT table, a simple pr_err(FW_BUG) print on failure and a fallback to using
the regular table. Lets see how long this lasts :-)
Intel-SIG: commit 528d89a4707e x86/topo: Fix SNC topology mess.
Backport x86/topo: SNC Divination
Fixes: 4d6dd05d07d0 ("sched/topology: Fix sched domain build error for GNR, CWF in SNC-3 mode")
Reported-by: Kyle Meyer <kyle.meyer@hpe.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Chen Yu <yu.c.chen@intel.com>
Tested-by: Kyle Meyer <kyle.meyer@hpe.com>
Link: https://patch.msgid.link/20260303110100.238361290@infradead.org
[ Aubrey Li: amend commit log ]
Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While testing Granite Rapids (GNR) and Clearwater Forest (CWF) systems in SNC-3 mode, we encountered sched domain build errors in dmesg. The scheduler domain code did not expect asymmetric node distances from a local node to multiple nodes in a remote package. As a result, remote nodes ended up being grouped partially with local nodes with asymemtric groupings, and creating too many levels in the NUMA sched domain hierarchy.
To address this, we simplify remote node distances for the purpose of sched domain construction on GNR and CWF. Specifically, we replace the individual distances to nodes within the same remote package with their average distance. This resolves the domain build errors and reduces the number of NUMA sched domain levels.
The actual SLIT NUMA node distances are still preserved separately, in case they are needed when building sched domains. NUMA balancing continues to use the true distances when selecting a closer remote node for a task’s numa_group.
The following two commits backported:
as well as its necessary dependencies:
Testing result w/o fixes:
[ 8.260954] CPU0 attaching sched-domain(s):[ 8.261112] domain-0: span=0,192 level=SMT[ 8.262111] groups: 0:{ span=0 cap=976 }, 192:{ span=192 cap=1022 }[ 8.263111] domain-1: span=0-31,192-223 level=MC[ 8.264110] groups: 0:{ span=0,192 cap=1998 }, 1:{ span=1,193 cap=2046 }, 2:{ span=2,194 cap=2045 }, 3:{ span=3,195 cap=2046 }, 4:{ span=4,196 cap=2044 }, 5:{ span=5,197 cap=2045 }, 6:{ span=6,198 cap=2046 }, 7:{ span=7,199 cap=2045 }, 8:{ span=8,200 cap=2045 }, 9:{ span=9,201 cap=2047 }, 10:{ span=10,202 cap=2045 }, 11:{ span=11,203 cap=2047 }, 12:{ span=12,204 cap=2044 }, 13:{ span=13,205 cap=2045 }, 14:{ span=14,206 cap=2045 }, 15:{ span=15,207 cap=2045 }, 16:{ span=16,208 cap=2045 }, 17:{ span=17,209 cap=2048 }, 18:{ span=18,210 cap=2047 }, 19:{ span=19,211 cap=2045 }, 20:{ span=20,212 cap=2045 }, 21:{ span=21,213 cap=2046 }, 22:{ span=22,214 cap=2048 }, 23:{ span=23,215 cap=2045 }, 24:{ span=24,216 cap=2047 }, 25:{ span=25,217 cap=2046 }, 26:{ span=26,218 cap=2046 }, 27:{ span=27,219 cap=2045 }, 28:{ span=28,220 cap=2046 }, 29:{ span=29,221 cap=2046 }, 30:{ span=30,222 cap=2044 }, 31:{ span=31,223 cap=2046 }[ 8.265119] domain-2: span=0-63,192-255 level=NUMA[ 8.266110] groups: 0:{ span=0-31,192-223 cap=65413 }, 32:{ span=32-63,224-255 cap=65457 }[ 8.267111] domain-3: span=0-95,192-287 level=NUMA[ 8.268110] groups: 0:{ span=0-63,192-255 mask=0-31,192-223 cap=130870 }, 64:{ span=32-95,224-287 mask=64-95,256-287 cap=131001 }[ 8.269111] domain-4: span=0-127,192-319 level=NUMA[ 8.270110] groups: 0:{ span=0-95,192-287 cap=196381 }, 96:{ span=96-127,288-319 cap=65451 }[ 8.271111] domain-5: span=0-127,160-319,352-383 level=NUMA[ 8.272110] groups: 0:{ span=0-127,192-319 mask=0-31,192-223 cap=261832 }, 160:{ span=160-191,352-383 cap=65475 }[ 8.273112] domain-6: span=0-383 level=NUMA[ 8.274110] groups: 0:{ span=0-127,160-319,352-383 mask=0-31,192-223 cap=327307 }[ 8.275111] ERROR: groups don't span domain->spanTesting result w/ fixes:
[ 8.187368] CPU0 attaching sched-domain(s):[ 8.188143] domain-0: span=0,192 level=SMT[ 8.189142] groups: 0:{ span=0 cap=887 }, 192:{ span=192 }[ 8.190141] domain-1: span=0-31,192-223 level=MC[ 8.191141] groups: 0:{ span=0,192 cap=1911 }, 1:{ span=1,193 cap=2021 }, 2:{ span=2,194 cap=2038 }, 3:{ span=3,195 cap=2040 }, 4:{ span=4,196 cap=2039 }, 5:{ span=5,197 cap=2045 }, 6:{ span=6,198 cap=2041 }, 7:{ span=7,199 cap=2041 }, 8:{ span=8,200 cap=2042 }, 9:{ span=9,201 cap=2033 }, 10:{ span=10,202 cap=2033 }, 11:{ span=11,203 cap=2033 }, 12:{ span=12,204 cap=2045 }, 13:{ span=13,205 cap=2027 }, 14:{ span=14,206 cap=2038 }, 15:{ span=15,207 cap=2035 }, 16:{ span=16,208 cap=2044 }, 17:{ span=17,209 cap=2044 }, 18:{ span=18,210 cap=2039 }, 19:{ span=19,211 cap=2042 }, 20:{ span=20,212 cap=2041 }, 21:{ span=21,213 cap=2048 }, 22:{ span=22,214 cap=2036 }, 23:{ span=23,215 cap=2048 }, 24:{ span=24,216 cap=2021 }, 25:{ span=25,217 cap=2043 }, 26:{ span=26,218 cap=2044 }, 27:{ span=27,219 cap=2041 }, 28:{ span=28,220 cap=2041 }, 29:{ span=29,221 cap=2037 }, 30:{ span=30,222 cap=2036 }, 31:{ span=31,223 cap=2048 }[ 8.192149] domain-2: span=0-63,192-255 level=NUMA[ 8.193141] groups: 0:{ span=0-31,192-223 cap=65115 }, 32:{ span=32-63,224-255 cap=65201 }[ 8.194142] domain-3: span=0-95,192-287 level=NUMA[ 8.195141] groups: 0:{ span=0-63,192-255 mask=0-31,192-223 cap=130316 }, 64:{ span=32-95,224-287 mask=64-95,256-287 cap=130714 }[ 8.196142] domain-4: span=0-383 level=NUMA[ 8.197141] groups: 0:{ span=0-95,192-287 cap=195692 }, 96:{ span=96-191,288-383 cap=195639 }