Re: [PATCH 01/19] sched/fair: Add infrastructure for cache-aware load balancing

[Chen, Yu C]

Hi Prateek,

On 10/27/2025 12:47 PM, K Prateek Nayak wrote:
> Hello Tim,
>
> On 10/11/2025 11:54 PM, Tim Chen wrote:
>
> [..snip..]
>
> >   static s64 update_se(struct rq *rq, struct sched_entity *se)
> >   {
> >   	u64 now = rq_clock_task(rq);
> > @@ -1174,6 +1176,7 @@ static s64 update_se(struct rq *rq, struct sched_entity *se)
> >   
> >   		trace_sched_stat_runtime(running, delta_exec);
> >   		account_group_exec_runtime(running, delta_exec);
> > +		account_mm_sched(rq, donor, delta_exec);
>
> Shouldn't we attribute this to "rq->curr"/"running" since that is the
> task which is actually running on the CPU (with "rq->curr->mm" being the
> one that is being used on CPU) as opposed to the "donor" which is just
> providing the vruntime context?

This is a good point. I'm not quite familiar with proxy execution,
but after studying commit aa4f74dfd42b ("sched: Fix runtime accounting
w/ split exec & sched contexts"), it seems that if it is related to the
raw running time, the duration should be accumulated to rq->curr, the
 actual proxy task. If it is related to vruntime - which might be
directly tied to the task selection/duration strategy-we should
accumulate the delta to rq->donor, whose context is being borrowed. Is
this a convention, or did we encounter any issues before aa4f74dfd42b?

I think it makes sense to change to rq->curr. As in "[PATCH
16/19] sched/fair: Exclude processes with many threads from cache-aware
scheduling," we use rq->curr to determine how many active threads the
process has. We should also change rq->donor to rq->curr in this
[PATCH 1/19] to keep them consistent.


thanks,
Chenyu
> >   
> >   		/* cgroup time is always accounted against the donor */
> >   		cgroup_account_cputime(donor, delta_exec);