Re: [PATCH 0/3] sched: Fix proxy-exec use of curr and donor

[Jemmy Wong <jemmywong512@gmail.com>]

Hi Hui,

Agreed on 2/3. Your Sep 2 patch makes the same task_sched_runtime()
change: task_current() for the execution context, and update_curr()
through the donor class. I'll drop it.

Agreed on 3/3 as well. Andrea's patch is earlier, and it removes the
nr_running == 1 guard that mine keeps. With that guard the bandwidth
test does not run while a proxy leaves both tasks queued. I'll drop
this one too.

Thanks for the pointers.

Jemmy

> On Oct 9, 2026, at 12:07 PM, Hui Su <sh_def@163.com> wrote:
> 
>> Yes. My first patch and Hui's v5 2/4 and 3/4 move the NUMA and cache
>> ticks onto rq->curr when that task is fair. Hui's 1/4 is the right
>> shape: task_tick() runs the donor class and, when a proxy crosses
>> classes, the execution class as well. A fair lock holder whose donor
>> is RT or deadline still gets those hooks. My patch only changes
>> task_tick_fair(), so that case stays missing. I'll drop it.
> 
> Thanks Jemmy,
> 
> Yes, agreed on 1/3.
> 
> For 2/3, I think this also overlaps with an earlier standalone patch I
> posted on Sep 2:
> 
> [PATCH] sched/core: fix task_sched_runtime() for proxy execution
> Message-ID: <20260902112539.879979-1-sh_def@163.com>
> https://lore.kernel.org/r/20260902112539.879979-1-sh_def@163.com/
> 
> It makes the same two changes in task_sched_runtime(): test whether @p is
> the execution context with task_current(), while still invoking
> update_curr() through rq->donor->sched_class.
> 
> For 3/3, Andrea has an earlier patch, first posted on Jul 16, addressing
> the same NOHZ CFS bandwidth issue:
> 
> sched: Make NOHZ CFS bandwidth checks follow proxy donor
> https://lore.kernel.org/r/20260716132229.61603-2-arighi@nvidia.com/
> 
> In particular, that patch also removes the nr_running == 1 restriction.
> As Andrea points out, a retained proxy donor keeps both the donor and
> mutex owner queued, so keeping that restriction would skip the bandwidth
> check in the active proxy case.
> 
> Thanks,
> Hui
>