Re: [PATCH v3 05/21] sched/cache: Assign preferred LLC ID to processes

[Chen, Yu C]

On 2/15/2026 2:36 AM, Madadi Vineeth Reddy wrote:
> On 11/02/26 03:48, Tim Chen wrote:

[ ... ]

> > @@ -1311,6 +1343,11 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
> >   		if (mm->sc_stat.cpu != -1)
> >   			mm->sc_stat.cpu = -1;
> >   	}
> > +
> > +	mm_sched_llc = get_pref_llc(p, mm);
> > +
> > +	if (p->preferred_llc != mm_sched_llc)
> > +		p->preferred_llc = mm_sched_llc;
>
> This writes to p->preferred_llc without using WRITE_ONCE(). If later patches read p->preferred_llc from
> load balancing or migration paths on other CPUs, wouldn't this create a data race?

I suppose you are referring to data inconsistency between CPUs, as 
READ/WRITE_ONCE()
make sure that the latest data is always read from/written to memory rather
than from/to registers.

> For example:
> CPU 0: Task is running, account_mm_sched() writes p->preferred_llc
> CPU 1: Load balancer reads p->preferred_llc to make migration decisions
>
> Should this use WRITE_ONCE() and READ_ONCE() at the read sites, unless all accesses are guaranteed to be
> under rq->lock?

Actually, I found that p->preferred_llc is only read during task 
enqueue/dequeue in
account_llc_enqueue() and account_llc_dequeue(), which are protected by 
the rq lock.
However, after reviewing the code again, I noticed that in 
migrate_degrades_llc()
(part of the load balance logic), we should check the task's 
preferred_llc instead
of the task's current LLC obtained via task_llc(p). We will therefore 
switch to
using READ/WRITE_ONCE for accesses to this variable in 
migrate_degrades_llc().

thanks,
Chenyu