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

[Tim Chen]

On Sat, 2026-02-14 at 23:34 +0800, Chen, Yu C wrote:
> 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.
> 

There is no particular advantage to prevent cpu_epoch update during mm
initialization by holding the cpu_epoch lock.  The difference with using
a slightly stale cpu epoch will be one epoch in __update_mm_sched()
which will be quickly aged out in the subsequent updates. 

However holding the lock could affect scalability and slow down workload that forks
short lived processes frequently and hence the choice.

Tim