Re: [PATCH v3 01/21] sched/cache: Introduce infrastructure for cache-aware load balancing

[Chen, Yu C]

Hi Vineeth,

On 2/14/2026 8:26 PM, Madadi Vineeth Reddy wrote:
> Hi Tim,
> Thanks for the patch series.
>
> On 11/02/26 03:48, Tim Chen wrote:
> > From: "Peter Zijlstra (Intel)" <peterz@xxxxxxxxxxxxx>
> >
> > Adds infrastructure to enable cache-aware load balancing,
> > which improves cache locality by grouping tasks that share resources
> > within the same cache domain. This reduces cache misses and improves
> > overall data access efficiency.
>
> [..snip..]
>
> > +void mm_init_sched(struct mm_struct *mm,
> > +		   struct sched_cache_time __percpu *_pcpu_sched)
> > +{
> > +	unsigned long epoch;
> > +	int i;
> > +
> > +	for_each_possible_cpu(i) {
> > +		struct sched_cache_time *pcpu_sched = per_cpu_ptr(_pcpu_sched, i);
> > +		struct rq *rq = cpu_rq(i);
> > +
> > +		pcpu_sched->runtime = 0;
> > +		pcpu_sched->epoch = rq->cpu_epoch;
> > +		epoch = rq->cpu_epoch;
>
> Shouldn't cpu_epoch be read under cpu_epoch_lock, similar to how fraction_mm_sched()
> and __update_mm_sched() acquire the lock before accessing this field?

My understanding is that __update_mm_sched() updates rq->cpu_epoch in 
two steps:
first, it reads the current value, and then it writes the new value back 
to it
(as seen in the operation rq->cpu_epoch += n). For this reason, a lock 
is required
to prevent race conditions during concurrent updates across multiple CPUs.

In contrast, reading rq->cpu_epoch in mm_init_sched() is a single atomic 
operation,
and it is acceptable to read a stale value in this scenario - thus, we 
can safely
perform an unprotected read of this field here.

thanks,
Chenyu
> Thanks,
> Vineeth