RE: [RFC PATCH 0/8] sched: Extend cache-aware scheduling into topology-aware scheduling

[Jianyong Wu]

Hi Peter,

> -----Original Message-----
> From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Sent: Thursday, June 25, 2026 4:42 PM
> To: Jianyong Wu <wujianyong@xxxxxxxx>
> Cc: mingo@xxxxxxxxxx; juri.lelli@xxxxxxxxxx; vincent.guittot@xxxxxxxxxx;
> dietmar.eggemann@xxxxxxx; rostedt@xxxxxxxxxxx; bsegall@xxxxxxxxxx;
> mgorman@xxxxxxx; vschneid@xxxxxxxxxx; kprateek.nayak@xxxxxxx;
> sshegde@xxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> yu.c.chen@xxxxxxxxx; tim.c.chen@xxxxxxxxxxxxxxx; justin.he@xxxxxxx;
> Yuan Zhong <zhongyuan@xxxxxxxx>; Zhiwei Ying <yingzhiwei@xxxxxxxx>;
> Huangsj <huangsj@xxxxxxxx>
> Subject: Re: [RFC PATCH 0/8] sched: Extend cache-aware scheduling into
> topology-aware scheduling
> 
> On Thu, Jun 25, 2026 at 11:07:51AM +0800, Jianyong Wu wrote:
> > The current cache-aware scheduling implementation adopts an
> > LLC-centric task aggregation model. While effective for workloads
> > that fit within a single LLC domain, this design is fundamentally
> > limited by a fixed aggregation scope that cannot scale across
> > scheduling domains.
> >
> > This leads to a single structural limitation: the lack of
> > topology-scalable task aggregation. When workload size exceeds
> > the capacity of an LLC domain, the scheduler cannot extend
> > aggregation to higher-level domains, and locality cannot be
> > preserved effectively. At the same time, higher-level topology
> > information such as NUMA domains cannot be consistently utilized
> > for placement decisions.
> >
> > This patch set addresses this limitation by extending
> > cache-aware scheduling into topology-aware task aggregation.
> > The aggregation scope becomes hierarchical and can dynamically
> > expand or contract across scheduling domains based on workload
> > demand.
> >
> > Task aggregation starts at MC or LLC domains under light load,
> > and expands to NUMA and higher-level domains as load increases,
> > and contracts when load decreases.
> 
> Urgh,... that only really works if the topology has a low branching
> factor.
> 
> I would much rather see things move towards a mask of cache domains,
> rather than any single one, where the number of bits in the mask is
> minimal vs the concurrency.

OK, let me try this.
> 
> This has already been mentioned a number of times, which seems to
> suggest you've not actually been reading along very well :-(

Sorry for missing the earlier discussion on this.

Thanks
Jianyong