Re: [PATCH RFC] sched/proxy: Defer donor commit until after proxy resolution

[Xukai Wang]

Hi Prateek,

On 2026/7/13 12:22, K Prateek Nayak wrote:
> Hello Xukai,
> I've added John on this thread in case he knows of any dependency
> in the find_proxy_task() bits that rely on rq->donor being updated
> with the recent pick (I, personally am not aware of any but there
> might be some dependency that eventually gets added with the full
> proxy series that I haven't yet considered).
Thanks for taking a look and looping John in.
>> In that run, I got:
>> find_call                         5407
>> find_success                       523
>> find_idle                         1660
>> find_null                         3224
>>
>> spec_commit_blocked               5407
>> spec_commit_then_null             3224
>> spec_commit_then_idle             1660
>> spec_commit_then_success           523
>>
>> null_deactivate_no_mutex             6
>> null_deactivate_no_owner           125
>> null_deactivate_owner_not_runnable 962
>> null_migrate                      2131
> I think the chain-migration bits can bring down some of these
> null_migrate calls substantially.
>
>> null_retry_same_donor                0
>> null_retry_diff_donor             2258
>> null_retry_to_idle                 966
> Seems like you mostly have one task that keeps getting migrated to the
> owner's CPU.、
Yes, the workload is intentionally and the waiter/holder placement can
indeed make the test repeatedly migrate a task toward the owner's CPU.
>> Based on your comments, I am thinking of restructuring the patch like this.
>>
>> First, move the final put_prev_set_next_task()/rq_set_donor() out of the
>> proxy/non-proxy branches. I think the common commit target still needs to
>> be the donor rather than next, because after find_proxy_task(), next may be
>> the proxy owner that will actually run, while donor is still the selected
>> scheduling donor/accounting context:
> You are right! I had not booted into a kernel with my suggested changes
> to have realized that mistake :-)
...
> Your suggestions look correct to me. Perhaps you can send a v2 including
> John and we can take a look.
...
> Just the patches should be fine. I can crunch the performance numbers
> from my side with schedstats and update on the threads.
OK, I will prepare a v2 with the structure discussed here.

-- 
Best regards,
Xukai