Re: [PATCH v3 00/21] Cache Aware Scheduling

[Qais Yousef <qyousef@layalina.io>]

On 02/20/26 10:14, Tim Chen wrote:

> > > Another reason why we moved away from doing things in the wake up
> > > path is load imbalance consideration. Wake up path does not have
> > > the most up to date load information in the LLC sched domains as
> > > in the load balance path. So you may actually have everyone rushed
> > 
> > What's the reason wake up doesn't have the latest info? Is this a limitation of
> > these large systems where stats updates are too expensive to do? Is it not
> > fixable at all?
> 
> You will need to sum the load for each run queue for each LLC to get
> an accurate picture.  That will be too expensive on the wake up path.

I am probably missing something obvious. But it seems enqueue/dequeue + TICK
are not keeping stats enough up-to-date for wakeup path to rely on. I need to
read this code more.

I could be wrong, but as I was trying to highlight in other places, I think the
fact we tag all tasks belonging to a process as needing to stay together is
exaggerating this problem. First every process is assumed to need to stay
within the same LLC, and every task within the process. The wake up path by
design now has a more difficult job and needs to look harder compared to if the
tagging was more conservative. And I can appreciate defining and teaching
regular LB that some imbalances are okay under these situations is hard. It is
sort of overcommit situation by design.

Anyway. As I was trying to tell Peter, I am trying to think how  we can tie all
these similar stories together. I hope once we can provide sensible way to tag
tasks we can get wake up path + push lb to work easily as then we should have
a handful of tasks asking to co-locate which is much easier to manage.