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

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Oct 28, 2026 at 09:10:00AM +0530, K Prateek Nayak wrote:
> On 10/27/2026 5:43 PM, Kayra Cizmeci wrote:
> >>> 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?
> 
> Yup! on_cpu / task_current() gets dealt at sched_info_switch()
> which will enqueue the signal if the task is preempted.

Can we record this in a comment; so that the people who come after us
(most likely our older selves) aren't left wondering ;-)