linux-kernel - Re: [PATCH v4 1/2] sched: Create architecture specific sched domain distances

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6a650359-d106-453a-a5a3-24b3750a05d2@intel.com>
Date: Sat, 27 Sep 2025 20:34:25 +0800
From: "Chen, Yu C" <yu.c.chen@...el.com>
To: Tim Chen <tim.c.chen@...ux.intel.com>, Peter Zijlstra
	<peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>
CC: Juri Lelli <juri.lelli@...hat.com>, Dietmar Eggemann
	<dietmar.eggemann@....com>, Ben Segall <bsegall@...gle.com>, Mel Gorman
	<mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>, Tim Chen
	<tim.c.chen@...el.com>, Vincent Guittot <vincent.guittot@...aro.org>, "Len
 Brown" <len.brown@...el.com>, <linux-kernel@...r.kernel.org>, K Prateek Nayak
	<kprateek.nayak@....com>, "Gautham R . Shenoy" <gautham.shenoy@....com>,
	"Zhao Liu" <zhao1.liu@...el.com>, Vinicius Costa Gomes
	<vinicius.gomes@...el.com>, Arjan Van De Ven <arjan.van.de.ven@...el.com>
Subject: Re: [PATCH v4 1/2] sched: Create architecture specific sched domain
 distances

On 9/20/2025 1:50 AM, Tim Chen wrote:
> 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.
> 
> Co-developed-by: Vinicius Costa Gomes <vinicius.gomes@...el.com>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@...el.com>
> Signed-off-by: Tim Chen <tim.c.chen@...ux.intel.com>

[snip]

> @@ -1591,10 +1591,12 @@ static void claim_allocations(int cpu, struct sched_domain *sd)
>   enum numa_topology_type sched_numa_topology_type;
>   
>   static int			sched_domains_numa_levels;
> +static int			sched_numa_node_levels;

I agree that the benefit of maintaining two NUMA distances - one for the
sched_domain and another for the NUMA balancing/page allocation policy - is
to avoid complicating the sched_domain hierarchy while preserving the
advantages of NUMA locality.

Meanwhile, I wonder if we could also add a "orig" prefix to the original
NUMA distance. This way, we can quickly understand its meaning later.
For example,
sched_orig_node_levels
sched_orig_node_distance

>   static int			sched_domains_curr_level;
>   
>   int				sched_max_numa_distance;
>   static int			*sched_domains_numa_distance;
> +static int			*sched_numa_node_distance;
>   static struct cpumask		***sched_domains_numa_masks;
>   #endif /* CONFIG_NUMA */
>   
> @@ -1808,10 +1810,10 @@ bool find_numa_distance(int distance)
>   		return true;
>   
>   	rcu_read_lock();
> -	distances = rcu_dereference(sched_domains_numa_distance);
> +	distances = rcu_dereference(sched_numa_node_distance);
>   	if (!distances)
>   		goto unlock;
> -	for (i = 0; i < sched_domains_numa_levels; i++) {
> +	for (i = 0; i < sched_numa_node_levels; i++) {
>   		if (distances[i] == distance) {
>   			found = true;
>   			break;
> @@ -1887,14 +1889,48 @@ static void init_numa_topology_type(int offline_node)
>   
>   #define NR_DISTANCE_VALUES (1 << DISTANCE_BITS)
>   
> -void sched_init_numa(int offline_node)
> +/*
> + * An architecture could modify its NUMA distance, to change
> + * grouping of NUMA nodes and number of NUMA levels when creating
> + * NUMA level sched domains.
> + *
> + * A NUMA level is created for each unique
> + * arch_sched_node_distance.
> + */
> +static bool __modified_sched_node_dist = true;
> +
> +int __weak arch_sched_node_distance(int from, int to)
>   {
> -	struct sched_domain_topology_level *tl;
> -	unsigned long *distance_map;
> +	if (__modified_sched_node_dist)
> +		__modified_sched_node_dist = false;
> +
> +	return node_distance(from, to);
> +}
> +
> +static bool modified_sched_node_distance(void)
> +{
> +	/*
> +	 * Call arch_sched_node_distance()
> +	 * to determine if arch_sched_node_distance
> +	 * has been modified from node_distance()
> +	 * to arch specific distance.
> +	 */
> +	arch_sched_node_distance(0, 0);
> +	return __modified_sched_node_dist;
> +}
> +

If our goal is to figure out whether the arch_sched_node_distance()
has been overridden, how about the following alias?

int __weak arch_sched_node_distance(int from, int to)
{
	return __node_distance(from, to);
}
int arch_sched_node_distance_original(int from, int to) __weak 
__alias(arch_sched_node_distance);

static bool arch_sched_node_distance_is_overridden(void)
{
	return arch_sched_node_distance != arch_sched_node_distance_original;
}

so arch_sched_node_distance_is_overridden() can replace 
modified_sched_node_distance()

thanks,
Chenyu