Re: [PATCH] sched/stats: Fix run_delay over-count for proxy-migrated blocked donors

From: Kayra Cizmeci

Date: Tue Oct 27 2026 - 05:55:43 EST


On Tue, Oct 27, 2026 at 03:15:40PM +0530, K Prateek Nayak wrote:
> On 10/27/2026 12:22 PM, Kayra Cizmeci wrote:
> > I think this fixes the issue. BTW I think this should skip curr, no?
> > On a case like this:
> >
> > C holds M1 in CPU0, D waits that mutex in CPU1. A holds mutex M2 in
> > CPU2. B is the working task on CPU1 but it wants mutex M2 and we enter
> > __schedule(). B gets is_blocked. D gets chosen. We open the rq lock to
> > get D to CPU0. While this happens A drops the mutex and wakes up B.
> > we enter ttwu_runnable() and B is still curr. And we start the timer.
>
> Good catch that!
>
> > Or am I MISSSING something?
>
> I can't believe something like wait time accounting can get this
> complicated! Anyhow, We can perhaps call sched_info_enqueue() in

TBH, me neither :-).

> ttwu_runnable() instead of proxy_needs_return() like:

I was thinking about that too! LGTM. FWIW, this depends
on is_blocked check in sched_info_enqueue().

Wei, what do you think? Will this work for you?

>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 04b62c16fa8c..d5758b78b741 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3956,6 +3956,8 @@ static int ttwu_runnable(struct task_struct *p, int wake_flags)
> * it should preempt the task that is current now.
> */
> wakeup_preempt(rq, p, wake_flags | WF_TTWU_RQ);
> + /* Start accounting wait time. */
> + sched_info_enqueue(rq, p);
> }
> ttwu_do_wakeup(p);
> return 1;
> ---
>
> --
> Thanks and Regards,
> Prateek
>

Thanks!

Kayra