Re: [Patch v4 01/22] sched/cache: Introduce infrastructure for cache-aware load balancing

[Tim Chen]

On Thu, 2026-04-09 at 14:41 +0200, Peter Zijlstra wrote:
> On Wed, Apr 01, 2026 at 02:52:13PM -0700, Tim Chen wrote:
> > +static inline
> > +void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
> > +{
> > +	struct sched_cache_time *pcpu_sched;
> > +	struct mm_struct *mm = p->mm;
> > +	unsigned long epoch;
> > +
> > +	if (!sched_cache_enabled())
> > +		return;
> > +
> > +	if (p->sched_class != &fair_sched_class)
> > +		return;
> > +	/*
> > +	 * init_task, kthreads and user thread created
> > +	 * by user_mode_thread() don't have mm.
> > +	 */
> > +	if (!mm || !mm->sc_stat.pcpu_sched)
> > +		return;
> > +
> > +	pcpu_sched = per_cpu_ptr(p->mm->sc_stat.pcpu_sched, cpu_of(rq));
> > +
> > +	scoped_guard (raw_spinlock, &rq->cpu_epoch_lock) {
> > +		__update_mm_sched(rq, pcpu_sched);
> > +		pcpu_sched->runtime += delta_exec;
> > +		rq->cpu_runtime += delta_exec;
> > +		epoch = rq->cpu_epoch;
> > +	}
> > +
> > +	/*
> > +	 * If this process hasn't hit task_cache_work() for a while, or it
> > +	 * has only 1 thread, invalidate its preferred state.
> > +	 */
> > +	if (time_after(epoch,
> > +		       READ_ONCE(mm->sc_stat.epoch) + EPOCH_LLC_AFFINITY_TIMEOUT) ||
> 
> I really think that:
> 
> 	if (epoch - READ_ONCE(mm->sc_stat.epoch) > EPOCH_LLC_AFFINITY_TIMEOUT)

Sure. We can change it.

> 
> is simpler to read.
> 
> 
> > +	    get_nr_threads(p) <= 1) {
> 
> And this, I just noticed this, why are we excluding tasks with one
> thread? The comment just states we are (doh), but utterly fails to
> explain why.

The thought was that for a single thread, we will tend to place it
in same LLC as it was previously running with cache hot.  Incurring
the added cost of tracking its residency in LLC is uneeded.

Tim

> 
> > +		if (mm->sc_stat.cpu != -1)
> > +			mm->sc_stat.cpu = -1;
> > +	}
> > +}