RE: [RFC PATCH v2 02/23] sched/topology: Introduce a NUMA distance matrix with unique distance values

[Jianyong Wu <wujianyong@hygon.cn>]

Hi Tim,

> -----Original Message-----
> From: Tim Chen <tim.c.chen@linux.intel.com>
> Sent: Friday, October 2, 2026 6:04 AM
> To: Jianyong Wu <wujianyong@hygon.cn>; Peter Zijlstra
> <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>; Juri Lelli <juri.lelli@redhat.com>;
> Vincent Guittot <vincent.guittot@linaro.org>; Chen Yu
> <yu.c.chen@intel.com>; Dietmar Eggemann
> <dietmar.eggemann@arm.com>; Steven Rostedt <rostedt@goodmis.org>;
> Ben Segall <bsegall@google.com>; Mel Gorman <mgorman@suse.de>;
> Valentin Schneider <vschneid@redhat.com>; K Prateek Nayak
> <kprateek.nayak@amd.com>; Shrikanth Hegde <sshegde@linux.ibm.com>;
> Phil Auld <pauld@redhat.com>; Andrew Morton
> <akpm@linux-foundation.org>; David Hildenbrand <david@kernel.org>;
> linux-kernel@vger.kernel.org; linux-mm@kvack.org;
> jianyong.wu@outlook.com; Yuan Zhong <zhongyuan@hygon.cn>; Huangsj
> <huangsj@hygon.cn>; Fengyu Wang <wangfengyu@hygon.cn>; Zhiwei Ying
> <yingzhiwei@hygon.cn>; justin.he@arm.com
> Subject: Re: [RFC PATCH v2 02/23] sched/topology: Introduce a NUMA
> distance matrix with unique distance values
> 
> On Mon, 2026-09-28 at 09:39 +0000, Jianyong Wu wrote:
> > Hi Tim,
> >
> >
> > Makes sense. So, what about the following solution?
> > Given a node affinity sequence, a move from src to dst improves the
> > affinity of every task whose preferred node i ranks dst better than src.
> The score
> > is then
> >
> > Di = raw_dist(src, i) - raw_dist(dst, i)
> > affinity_bias_i = position of src minus position of dst in node i's affinity
> >              sequence, counted among the nodes at the same
> distance from
> >              i (zero when Di is not zero)
> 
> Do we really need an affinity bias?  I think your intention is to use it for
> breaking a tie.
> If there is a tie in affinity score (without injecting bias),
> just use the position diff to break the tie.  Having a bias distorts
> the affinity score.
> 
>
I think there is a misunderstanding about the purpose of the bias.
It is not intended to break ties between affinity scores. I want the
score itself to reflect opportunities for aggregation, including moves
that leave the raw NUMA distance unchanged but follow the fixed node
affinity order.

That said, I agree with your concern about using artificial node
distances in the score calculation. The magnitude of an artificial
distance or rank difference should not determine the weight of those
aggregation opportunities.

How about the following approach?

When the source and destination have different raw distances to a task's
preferred node, we use the raw distance difference as the weight,
provided the destination is closer.

When those distances are equal, we use the fixed node affinity sequence
to determine eligibility. If the destination comes before the source,
each eligible task contributes a weight of 1. Otherwise, it contributes
nothing.

For each preferred node, the calculation would look like this.
A smaller rank means an earlier position in the affinity sequence.

  delta = node_distance(src_node, pref_node) -
              node_distance(dst_node, pref_node);

  if (delta > 0) {
    weight = delta;
  } else if (delta == 0 &&
  affi_node_rank_of(pref_node, dst_node) <
  affi_node_rank_of(pref_node, src_node)) {
    weight = 1;
  } else {
    continue;
  }

  score += numa_counts[pref_node] * weight;

Here, numa_counts[pref_node] is the number of tasks on the candidate
source that prefer pref_node.

This way, the fixed order determines eligibility, but the rank difference
does not affect the weight. For equal-distance moves, the contribution
simply counts the eligible tasks. A zero weight would lose that
information, even though these moves can help concentrate tasks on fewer
nodes.

This retains a minimal aggregation preference without using artificial
distance values in the calculation. Would this address your concern?

Thanks
Jianyong