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