[PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers

[PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers

[Chaohong Guo]

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

[PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs

[Chaohong Guo]

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

Re: [PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs

[Zhan Xusheng]

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

Re: [PATCH v2 2/2] sched/numa: Apply remote socket distance averaging for Hygon CPUs

[Guo Chaohong]

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

Re: [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers

[Ingo Molnar]

* 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

Re: [PATCH v2 1/2] x86/cpu/hygon: Introduce macros for hygon family numbers

[Guo Chaohong]

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