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

[Kayra Cizmeci]

On Tue, Oct 27, 2026 at 01:09:45PM +0100, Peter Zijlstra wrote:
> 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
> > ttwu_runnable() instead of proxy_needs_return() like:
> > 
> > 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;
> 
> So the normal wakeup path goes through enqueue_task() which gets the
> sched_info_enqueue() callback there. But yes, ttwu_runnable() does not
> go through that, and needs this additional call.
> 
> There is one more site in ttwu() that also doesn't go through
> enqueue_task() and that is the p==current thing at the top.

The counter already measures how much time a task waits for CPU,
curr is already is at the CPU so we don't need a call from there.

Or not?

Thanks,

Kayra