Re: [RFC PATCH v2 08/23] sched/topology: Introduce a per-CPU tasks NUMA preferred counter

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Sep 01, 2026 at 08:31:35AM +0000, Jianyong Wu wrote:

> > On Thu, Aug 27, 2026 at 08:28:01PM +0800, Jianyong Wu wrote:
> > > Like the existed task LLC preferred counter, sd->llc_counts, introduce
> > > sd->numa_counts to denotes the task number that prefer each NUMA node in
> > > a certain rq.
> > >
> > 
> > To what purpose? Is not the node occupancy the direct sum of its
> > constituent llc occupancy?
> 
> numa_counts is used by the affinity score in patch 12. It holds, for each
> NUMA node, the number of tasks on this rq whose preferred LLC falls in
> that node.
> 
> You're right that numerically it equals the per-node sum of llc_counts.
> The reason to keep it is granularity: NUMA-level load balance scores at
> node granularity (numa_counts[node] * distance_delta), while NODE-level
> balancing scores at LLC granularity (llc_counts[llc] * ...). Maintaining
> the node aggregate costs only a single llc_to_node() lookup (an O(1)
> array read) plus one increment in enqueue/dequeue, whereas recomputing
> the per-node sum would have to walk every LLC of a node each time the
> NUMA-level score is evaluated.

Consider the trade-off. Adding the accounting adds a cache-miss to every
enqueue/dequeue, while re-computing the value on-demand adds some little
cost to the balancing (slow) path.

If the llc_counts[] array is dense in node order, then it is likely all
relevant numbers are in a single line and computing the sum is in fact
fairly cheap.