Re: [PATCH v23 8/9] sched: Add blocked_donor link to task for smarter mutex handoffs

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello John,

On 11/11/2025 1:20 PM, John Stultz wrote:
> On Thu, Oct 30, 2025 at 10:03 PM K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>> On 10/30/2025 5:48 AM, John Stultz wrote:
>>> @@ -958,7 +964,34 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne
>>>
>>>       raw_spin_lock_irqsave(&lock->wait_lock, flags);
>>>       debug_mutex_unlock(lock);
>>> -     if (!list_empty(&lock->wait_list)) {
>>> +
>>> +     if (sched_proxy_exec()) {
>>> +             raw_spin_lock(&current->blocked_lock);
>>> +             /*
>>> +              * If we have a task boosting current, and that task was boosting
>>> +              * current through this lock, hand the lock to that task, as that
>>> +              * is the highest waiter, as selected by the scheduling function.
>>> +              */
>>> +             donor = current->blocked_donor;
>>> +             if (donor) {
>>
>> Any concerns on new waiters always appearing as donors and in-turn
>> starving the long time waiters on the list?
>>
> Hey!
>   So I'm not sure I'm quite following the concern. The scheduler picks
> "the most important task in that moment" to run and we just want to
> try to to pass the lock off to the donor that was boosting the lock
> owner.
> 
> Are you concerned that new waiters would somehow always be further
> left on the rq and would be selected as donors before other waiters on
> the rq?

Something along those lines. Say the first waiter on the wait list
has been around for a while but a new waiter keeps appearing, starts
proxy, gets the handoff, runs instead of the first waiter, and the
cycle repeats.

    owner: A (unlock)
    donor: C
    wait_list: B->C->D

    /* handoff to blocked_donor C */

    owner: C
    donor: C
    wait_list: B->D (->A) /* A appears again */


    /* C runs out of slice; B, D and then A take turn as donor */

    owner: C (unlock)
    donor: A
    wait_list: B->D->A

    /* Hand off to blocked donor A */

    owner: A
    donor: A
    wait_list: B->D (->C) /* C appears again */

    /*
     * A runs out of slice; B, D and C take turn as donor.
     * Whole thing repeats from top as C is selected for
     * handoff since it is the blocked donor.
     * B and D keep waiting for a long time for their turn.
     */

> I can sort of see the argument that "new waiters" would be
> running until they try to get the lock, so they may have timeslice
> still available to make them attractive to the scheduler as a donor,
> so maybe they would be re-selected as a donor right away. But I'm
> assuming at some point the fairness is going to cycle any waiting
> donors up to the front of the rq to act as a donor and then have the
> lock handed off.
> 
> That said, I don't see how this would be very much different from
> new/running optimistic spinners having a better chance at grabbing a
> lock then waiting tasks that aren't running.

Now that I take a closer look at optimistic spinning bits, the
"got the lock, yay!" path in __mutex_lock_common() doesn't seem
any different in behavior so I guess it is alright to hand off
to the proxy donor.

> 
> But let me know more about what you're thinking of, as I'd like to
> better understand it and see if I could contrive a test to produce
> this sort of concerning behavior.
> 
> thanks
> -john

-- 
Thanks and Regards,
Prateek