* [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers @ 2026-08-06 0:35 Chaohong Guo 2026-08-06 0:35 ` [PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs Chaohong Guo 2026-08-06 8:22 ` [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers Ingo Molnar 0 siblings, 2 replies; 6+ messages in thread From: Chaohong Guo @ 2026-08-06 0:35 UTC (permalink / raw) To: peterz, tim.c.chen, mingo, bp; +Cc: x86, linux-kernel Consolidate all magic numbers of hygon CPUs into a header file. The macros describe the family/model numbers of hygon CPUs. Co-developed-by: Zhiquan Li <lizhiquan@open-hieco.net> Signed-off-by: Zhiquan Li <lizhiquan@open-hieco.net> Signed-off-by: Chaohong Guo <guochaohong@open-hieco.net> --- arch/x86/include/asm/cpu_device_id.h | 2 ++ arch/x86/include/asm/hygon-family.h | 17 +++++++++++++++++ 2 files changed, 19 insertions(+) create mode 100644 arch/x86/include/asm/hygon-family.h diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h index c62d8fae52c3..2fa8018afecd 100644 --- a/arch/x86/include/asm/cpu_device_id.h +++ b/arch/x86/include/asm/cpu_device_id.h @@ -42,6 +42,8 @@ #include <linux/device-id/x86_cpu.h> /* Get the INTEL_FAM* model defines */ #include <asm/intel-family.h> +/* Hygon HFM model defines */ +#include <asm/hygon-family.h> /* And the X86_VENDOR_* ones */ #include <asm/processor.h> diff --git a/arch/x86/include/asm/hygon-family.h b/arch/x86/include/asm/hygon-family.h new file mode 100644 index 000000000000..2fb989acb433 --- /dev/null +++ b/arch/x86/include/asm/hygon-family.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * The helpers to support Hygon CPU specific code path. + */ + +#ifndef _ASM_X86_HYGON_FAMILY_H +#define _ASM_X86_HYGON_FAMILY_H + +#include <asm/processor.h> + +#define HFM(_family, _model) VFM_MAKE(X86_VENDOR_HYGON, _family, _model) + +#define HYGON_F18_M04 HFM(0x18, 4) +#define HYGON_F18_M06 HFM(0x18, 6) +#define HYGON_F18_M07 HFM(0x18, 7) + +#endif /* _ASM_X86_HYGON_FAMILY_H */ -- 2.18.2 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs 2026-08-06 0:35 [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers Chaohong Guo @ 2026-08-06 0:35 ` Chaohong Guo 2026-08-06 3:15 ` Zhan Xusheng 2026-08-06 8:22 ` [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers Ingo Molnar 1 sibling, 1 reply; 6+ messages in thread From: Chaohong Guo @ 2026-08-06 0:35 UTC (permalink / raw) To: peterz, tim.c.chen, mingo, bp; +Cc: x86, linux-kernel On Intel GNR/CWF platforms with SNC3 enabled, commit 4d6dd05d07d0 ("sched/topology: Fix sched domain build error for GNR, CWF in SNC-3 mode") introduced the use of averaged distances to remote‑socket nodes when constructing scheduling domains. This helped group remote‑socket NUMA nodes into the same scheduling group, improving load‑balancing decisions. Hygon model 7 can contain up to six dies per package. When NPS (NUMA per socket) is enabled, each package exposes six NUMA nodes. We observe the same issue as on GNR/CWF: the current domain construction incorrectly merges nodes from different sockets at higher NUMA levels,leading to suboptimal remote‑socket CPU selection during load balancing. The following diagram illustrates the node topology (two packages, six nodes each): package 0 package 1 ---------------------------------------------- | -------------------- | | | | | ------ ------- ------ ------ | 0 |------| 3 | | 6 |-------| 9 | ------ ------- ----- ----- | | | | ------- ------- ----- ------ | 5 |------| 2 | | 11 |-------| 8 | ------- ------- ----- ----- | | | | ------- ------- ----- ------ | 4 |------| 1 | | 10 |-------| 7 | ------ ------- ----- ------ | | | | | -------------------- | ---------------------------------------------- From the perspective of CPUs in node 0, sched domains: numa-level 1: [0] [3] [5] numa-level 2: [0, 3, 5] [2] [4] numa-level 3: [0, 2-5] [1-5] numa-level 4: [0-5] [9] numa-level 5: [0-5, 9] [6] [8] numa-level 6: [0-6, 8, 9] [7] [11] numa-level 7: [0-9] [1-11] NUMA level 5-7， nodes in different socket are grouped together,which caused CPUs in remote socket are chosen while load balancing. For better performace, we do the same as Intel is doing on intel GNR/CWF. That reduces sched domains to 4-level NUMA and eliminates cross-socket sched groups in each domain: numa-level 1: [0] [3] [5] numa-level 2: [0, 3, 5] [2] [4] numa-level 3: [0, 2-5] [1-5] numa-level 4: [0-5] [6-11] Co-developed-by: Zhiquan Li <lizhiquan@open-hieco.net> Signed-off-by: Zhiquan Li <lizhiquan@open-hieco.net> Signed-off-by: Chaohong Guo <guochaohong@open-hieco.net> -- 2.18.2 --- arch/x86/kernel/smpboot.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index cb999feb66b0..14a5fb92317c 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -675,17 +675,26 @@ int arch_sched_node_distance(int from, int to) { int d = node_distance(from, to); + if (topology_max_packages() == 1) + return d; + + /* Handle SNC-3/NPS-6 asymmetries. */ switch (boot_cpu_data.x86_vfm) { case INTEL_GRANITERAPIDS_X: case INTEL_ATOM_DARKMONT_X: - if (topology_max_packages() == 1 || - topology_num_nodes_per_package() < 3) - return d; - + if (topology_num_nodes_per_package() >= 3) + d = slit_cluster_distance(from, to); + break; + case HYGON_F18_M07: /* - * Handle SNC-3 asymmetries. + * Hygon model 7 CPUs have either 4 or 6 compute dies (aka CDD). All + * 6‑die variants share the same interconnect topology. Apply remote + * socket distance averaging if the CPU exposes 6 dies when NPS is + * enabled. */ - return slit_cluster_distance(from, to); + if (topology_num_nodes_per_package() >= 6) + d = slit_cluster_distance(from, to); + break; } return d; } -- 2.18.2 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs 2026-08-06 0:35 ` [PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs Chaohong Guo @ 2026-08-06 3:15 ` Zhan Xusheng 2026-08-06 5:25 ` Guo Chaohong 0 siblings, 1 reply; 6+ messages in thread From: Zhan Xusheng @ 2026-08-06 3:15 UTC (permalink / raw) To: Chaohong Guo, peterz, tim.c.chen, mingo, bp Cc: Zhan Xusheng, Zhiquan Li, x86, linux-kernel On Thu, Aug 06, 2026 at 08:35:09AM +0800, Chaohong Guo wrote: > For better performace, we do the same as Intel is doing on intel GNR/CWF. > That reduces sched domains to 4-level NUMA and eliminates cross-socket > sched groups in each domain: The refactor of arch_sched_node_distance() looks functionally equivalent for the existing Intel cases: hoisting the topology_max_packages() == 1 early return, and turning the "return d / return slit_cluster_distance()" branches into "d = slit_cluster_distance() when topology_num_nodes_per_package() >= 3", yields the same result for GRANITERAPIDS_X / ATOM_DARKMONT_X. So no change there, good. One thing I couldn't tell from the changelog: the referenced commit 4d6dd05d07d0 is titled "sched/topology: Fix sched domain build error for GNR, CWF in SNC-3 mode" -- i.e. on Intel the asymmetric SNC-3 distances made the sched-domain build actually fail. This patch is instead framed as a load-balancing improvement ("For better performace", "suboptimal remote-socket CPU selection"), and the diagram shows domains that do build (levels 1-7 listed). So: does the Hygon NPS-6 case also hit a sched-domain build error/warning (a functional fix, like the Intel one), or is it purely a load-balancing/performance change? If it is the latter, would you be able to include benchmark numbers showing the improvement? For a change to the NUMA distance function / domain shape that seems worth having, and it would also make clear how this differs from the Intel build-error fix it is modeled on. Minor, on 1/2: HYGON_F18_M04 and HYGON_F18_M06 are added but only HYGON_F18_M07 has a user in this series. Are the other two intended as a reference for the new header, or could they be added when a user shows up? Thanks, Zhan Xusheng ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs 2026-08-06 3:15 ` Zhan Xusheng @ 2026-08-06 5:25 ` Guo Chaohong 0 siblings, 0 replies; 6+ messages in thread From: Guo Chaohong @ 2026-08-06 5:25 UTC (permalink / raw) To: Zhan Xusheng, peterz, tim.c.chen, mingo, bp Cc: Zhan Xusheng, x86, linux-kernel On 8/6/2026 11:15 AM, Zhan Xusheng wrote: > On Thu, Aug 06, 2026 at 08:35:09AM +0800, Chaohong Guo wrote: >> For better performace, we do the same as Intel is doing on intel GNR/CWF. >> That reduces sched domains to 4-level NUMA and eliminates cross-socket >> sched groups in each domain: > > The refactor of arch_sched_node_distance() looks functionally equivalent > for the existing Intel cases: hoisting the topology_max_packages() == 1 > early return, and turning the "return d / return slit_cluster_distance()" > branches into "d = slit_cluster_distance() when > topology_num_nodes_per_package() >= 3", yields the same result for > GRANITERAPIDS_X / ATOM_DARKMONT_X. So no change there, good. > > One thing I couldn't tell from the changelog: the referenced commit > 4d6dd05d07d0 is titled "sched/topology: Fix sched domain build error for > GNR, CWF in SNC-3 mode" -- i.e. on Intel the asymmetric SNC-3 distances > made the sched-domain build actually fail. This patch is instead framed > as a load-balancing improvement ("For better performace", "suboptimal > remote-socket CPU selection"), and the diagram shows domains that do > build (levels 1-7 listed). > > So: does the Hygon NPS-6 case also hit a sched-domain build error/warning > (a functional fix, like the Intel one), or is it purely a > load-balancing/performance change? If it is the latter, would you be able > to include benchmark numbers showing the improvement? For a change to the > NUMA distance function / domain shape that seems worth having, and it > would also make clear how this differs from the Intel build-error fix it > is modeled on. We benchmarked MySQL, ClickHouse, and other representative workloads. The results showed performance improvements in all tested cases, with gains ranging from 5% . clickbench/clickhouse : 192 Base 10 rounds SNC3+No overlap 150 rounds Base SNC3+No overlap Base SNC3+No overlap $ query cold_run | hot_run1 | hot_run2 $ 1 0.0016 0.0014 12.50% | 0.0013 0.00102 21.54% | 0.001 0.001 0.00%$ 2 0.0836 0.07196 13.92% | 0.0153 0.01768 -15.56% | 0.0156 0.015413333 1.20%$ 3 0.1444 0.140353333 2.80% | 0.0148 0.014073333 4.91% | 0.0147 0.014246667 3.08%$ 4 0.4151 0.414906667 0.05% | 0.0176 0.015366667 12.69% | 0.0168 0.015206667 9.48%$ 5 0.5444 0.54358 0.15% | 0.1422 0.140606667 1.12% | 0.1447 0.140953333 2.59%$ 6 0.7963 0.795386667 0.11% | 0.1515 0.148833333 1.76% | 0.1489 0.148693333 0.14%$ 7 0.0046 0.004226667 8.12% | 0.0038 0.003946667 -3.86% | 0.0037 0.003866667 -4.50%$ 8 0.0264 0.023386667 11.41% | 0.0216 0.019186667 11.17% | 0.0214 0.019746667 7.73%$ 9 0.6561 0.653253333 0.43% | 0.1196 0.11574 3.23% | 0.117 0.114386667 2.23%$ 10 0.7967 0.79246 0.53% | 0.1256 0.123653333 1.55% | 0.1247 0.1222 2.00%$ 11 0.47 0.46812 0.40% | 0.0687 0.065393333 4.81% | 0.0691 0.066226667 4.16%$ 12 0.4955 0.493753333 0.35% | 0.0792 0.075866667 4.21% | 0.0799 0.077406667 3.12%$ 13 0.812 0.802613333 1.16% | 0.1564 0.154686667 1.10% | 0.1511 0.15128 -0.12%$ 14 1.2099 1.198433333 0.95% | 0.1807 0.178466667 1.24% | 0.1808 0.180213333 0.32%$ 15 0.8717 0.857206667 1.66% | 0.1547 0.142033333 8.19% | 0.1618 0.143266667 11.45%$ 16 0.4823 0.47796 0.90% | 0.0889 0.086666667 2.51% | 0.0872 0.085966667 1.41%$ 17 1.2846 1.270586667 1.09% | 0.2575 0.262233333 -1.84% | 0.2615 0.27116 -3.69%$ 18 1.2369 1.240953333 -0.33% | 0.2411 0.215066667 10.80% | 0.2262 0.211033333 6.70%$ 19 2.046 2.05788 -0.58% | 0.4103 0.421406667 -2.71% | 0.4662 0.426066667 8.61%$ 20 0.1586 0.158846667 -0.16% | 0.0024 0.00254 -5.83% | 0.0021 0.002 4.76%$ 21 4.8204 4.81756 0.06% | 0.0222 0.02148 3.24% | 0.0202 0.020206667 -0.03%$ 22 4.8637 4.85928 0.09% | 0.0161 0.014966667 7.04% | 0.0133 0.01314 1.20%$ 23 10.1773 10.03627333 1.39% | 0.5177 0.429133333 17.11% | 0.5251 0.454086667 13.52%$ 24 0.3491 0.340746667 2.39% | 0.0539 0.050406667 6.48% | 0.0489 0.04618 5.56%$ 25 0.8278 0.8248 0.36% | 0.054 .053033333 1.79% | 0.0403 0.0382 5.21%$ 26 0.7047 0.7044 0.04% | 0.0459 0.04642 -1.13% | 0.0436 0.045266667 -3.82%$ 27 0.8263 0.827233333 -0.11% | 0.0518 0.05786 -11.70% | 0.0394 0.038213333 3.01%$ 28 0.4877 0.486706667 0.20% | 0.0408 0.040753333 0.11% | 0.0408 0.041086667 -0.70%$ 29 4.2963 4.242473333 1.25% | 0.2718 0.256586667 5.60% | 0.2612 0.252573333 3.30%$ 30 0.1704 0.170693333 -0.17% | 0.0661 0.065826667 0.41% | 0.066 0.065826667 0.26%$ 31 0.6178 0.61514 0.43% | 0.095 .091386667 3.80% | 0.0959 0.088826667 7.38%$ 32 2.0294 2.024113333 0.26% | 0.1525 0.123653333 18.92% | 0.1508 0.11932 20.88%$ 33 2.2297 2.21918 0.47% | 0.5283 0.451426667 14.55% | 0.572 0.441673333 22.78%$ 34 5.156 5.056313333 1.93% | 0.8417 0.470013333 44.16% | 0.9473 0.4826 49.06%$ 35 5.1236 5.05868 1.27% | 0.7324 0.456533333 37.67% | 0.7682 0.466333333 39.30%$ 36 0.3046 0.295393333 3.02% | 0.0714 0.064266667 9.99% | 0.0679 0.062433333 8.05%$ 37 0.0744 0.073853333 0.73% | 0.0398 0.0392 1.51% | 0.0397 0.03976 -0.15%$ 38 0.039 0.03868 0.82% | 0.0265 0.025726667 2.92% | 0.0257 0.025273333 1.66%$ 39 0.0595 0.0592 0.50% | 0.0183 0.018686667 -2.11% | 0.0195 0.018413333 5.57%$ 40 0.1307 0.128733333 1.50% | 0.0762 0.074006667 2.88% | 0.0761 0.075753333 0.46%$ 41 0.0175 0.0178 -1.71% | 0.0123 0.01284 -4.39% | 0.0128 0.0128 0.00%$ 42 0.0174 0.017753333 -2.03% | 0.0135 0.01318 2.37% | 0.0132 0.013513333 -2.37%$ 43 0.0081 0.008226667 -1.56% | 0.0119 0.012333333 -3.64% | 0.0123 0.01282 -4.23%$ > > Minor, on 1/2: HYGON_F18_M04 and HYGON_F18_M06 are added but only > HYGON_F18_M07 has a user in this series. Are the other two intended as a > reference for the new header, or could they be added when a user shows up? > We plan to refactor Hygon CPU related code (e.g., node management, EDAC, etc.) and upstream more Hygon support in the future. Since some of these changes currently define macros in private files, we prefer to consolidate them into a common header to improve maintainability. thanks, -chaohong> Thanks, > Zhan Xusheng ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers 2026-08-06 0:35 [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers Chaohong Guo 2026-08-06 0:35 ` [PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs Chaohong Guo @ 2026-08-06 8:22 ` Ingo Molnar 2026-08-06 8:50 ` Guo Chaohong 1 sibling, 1 reply; 6+ messages in thread From: Ingo Molnar @ 2026-08-06 8:22 UTC (permalink / raw) To: Chaohong Guo; +Cc: peterz, tim.c.chen, bp, x86, linux-kernel * Chaohong Guo <guochaohong@open-hieco.net> wrote: > --- /dev/null > +++ b/arch/x86/include/asm/hygon-family.h > @@ -0,0 +1,17 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * The helpers to support Hygon CPU specific code path. > + */ > + > +#ifndef _ASM_X86_HYGON_FAMILY_H > +#define _ASM_X86_HYGON_FAMILY_H Why is the header guard ordering different from <asm/intel-family.h>: /* SPDX-License-Identifier: GPL-2.0 */ #ifndef _ASM_X86_INTEL_FAMILY_H #define _ASM_X86_INTEL_FAMILY_H /* * "Big Core" Processors (Branded as Core, Xeon, etc...) * Please follow the standard header guard ordering in <asm/hygon-family.h> as well. Thanks, Ingo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers 2026-08-06 8:22 ` [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers Ingo Molnar @ 2026-08-06 8:50 ` Guo Chaohong 0 siblings, 0 replies; 6+ messages in thread From: Guo Chaohong @ 2026-08-06 8:50 UTC (permalink / raw) To: Ingo Molnar; +Cc: peterz, tim.c.chen, bp, x86, linux-kernel I apologize for forgetting the error you pointed out in your previous review. I will correct it, diff --git a/arch/x86/include/asm/hygon-family.h b/arch/x86/include/asm/hygon-family.h new file mode 100644 index 000000000000..68e5af310980 --- /dev/null +++ b/arch/x86/include/asm/hygon-family.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_X86_HYGON_FAMILY_H +#define _ASM_X86_HYGON_FAMILY_H + +/* + * The helpers to support Hygon CPU specific code path. + */ + +#include <asm/processor.h> + +#define HFM(_family, _model) VFM_MAKE(X86_VENDOR_HYGON, _family, _model) + +#define HYGON_F18_M04 HFM(0x18, 4) +#define HYGON_F18_M06 HFM(0x18, 6) +#define HYGON_F18_M07 HFM(0x18, 7) + +#endif /* _ASM_X86_HYGON_FAMILY_H */ thanks, -Chaohong On 8/6/2026 4:22 PM, Ingo Molnar wrote: > > * Chaohong Guo <guochaohong@open-hieco.net> wrote: > >> --- /dev/null >> +++ b/arch/x86/include/asm/hygon-family.h >> @@ -0,0 +1,17 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +/* >> + * The helpers to support Hygon CPU specific code path. >> + */ >> + >> +#ifndef _ASM_X86_HYGON_FAMILY_H >> +#define _ASM_X86_HYGON_FAMILY_H > > Why is the header guard ordering different from <asm/intel-family.h>: > > /* SPDX-License-Identifier: GPL-2.0 */ > #ifndef _ASM_X86_INTEL_FAMILY_H > #define _ASM_X86_INTEL_FAMILY_H > > /* > * "Big Core" Processors (Branded as Core, Xeon, etc...) > * > > Please follow the standard header guard ordering in > <asm/hygon-family.h> as well. > > Thanks, > > Ingo ^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-08-06 8:50 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-08-06 0:35 [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers Chaohong Guo 2026-08-06 0:35 ` [PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs Chaohong Guo 2026-08-06 3:15 ` Zhan Xusheng 2026-08-06 5:25 ` Guo Chaohong 2026-08-06 8:22 ` [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers Ingo Molnar 2026-08-06 8:50 ` Guo Chaohong
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.