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

[K Prateek Nayak]

Hello Kayra,

On 10/27/2026 11:41 AM, Kayra Cizmeci wrote:
>> So all things considered, I think the following should work unless I'm
>> terribly mistaken yet again :-) I've left my reasoning as comments:
>>
>> diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
>> index ebe0a7765f98..c4c624deb25b 100644
>> --- a/kernel/sched/stats.h
>> +++ b/kernel/sched/stats.h
>> @@ -239,6 +239,15 @@ static inline void psi_account_irqtime(struct rq *rq, struct task_struct *curr,
>>  static inline void sched_info_dequeue(struct rq *rq, struct task_struct *t)
>>  {
>>  	unsigned long long delta = 0;
>> +	/*
>> +	 * If a task is blocked (blocked donor, delayed dequeue task),
>> +	 * do not account the queued time as runnable. A task that is
>> +	 * blocking would have already cleared the "last_queued"
>> +	 * indicator from sched_info_arrive() when it got a chance to
>> +	 * run on the CPU.
>> +	 */
>> +	if (t->is_blocked)
>> +		t->sched_info.last_queued = 0;
>>  
>>  	if (!t->sched_info.last_queued)
>>  		return;
>> @@ -290,7 +299,23 @@ static void sched_info_arrive(struct rq *rq, struct task_struct *t)
>>   */
>>  static inline void sched_info_enqueue(struct rq *rq, struct task_struct *t)
>>  {
>> -	if (!t->sched_info.last_queued)
>> +	/*
>> +	 * "t->is_blocked" is only cleared after the enqueue is done and
>> +	 * the task is woken up. If the task is blocked, update the
>> +	 * "last_queued" timestamp to that of last enqueue - if the task
>> +	 * is still blocked while it leaves the runqueue, this timestamp
>> +	 * is ignored and is cleared at sched_info_dequeue().
>> +	 *
>> +	 * To transition a task back to blocked after wakeup, it has to
>> +	 * run on the CPU and naturally reach a safe preemption point.
>> +	 * sched_info_arrive() will do the correct wait time accounting
>> +	 * based on the last "last_queued".
>> +	 *
>> +	 * Any movement of task after being marked not blocked will be
>> +	 * correctly captured as queued time at enqueue + dequeue
>> +	 * boundaries when "t->is_blocked" cleared.
>> +	 */
>> +	if (!t->sched_info.last_queued || t->is_blocked)
>>  		t->sched_info.last_queued = rq_clock(rq);
>>  }
>>  
>> ---
>>
>> That "t->is_blocked" check in sched_info_enqueue() may not be
>> necessary either but I've left it in there for now since I did my
>> quick testing with it.
> 
> 
> Hi Prateek,
> 
> IMO too doing this with is_blocked would be cleaner.
> 
> But I think this not works on a case where a donor is in a different CPU
> from its owner, like:
> 
> A holds the mutex M in CPU0, B is the waiter and its on CPU1.
> 
> proxy_migrate_task() gets B to CPU0.
>> After that, A suddenly wants to goto CPU1. And it goes.
> Now B goes back to its home CPU next to A.
> 
> Now in here, timer starts.
> 
> And suddenly A drops the mutex. Now B is not is_blocked.
> 
> Because B is back to its home CPU, there is no dequeue.
> Even if there was B is not is_blocked so timer wouldn't be reset.
> 
> Normally we need to add the time that task waited for itself.
> But in this case we add the time task waited for its mutex + for itself.
> 
> Or am I missssssing something?

Indeed. That is possible and can probably be fixed by doing a
sched_info_enqueue() in proxy_needs_return() for
task_cpu(p) == p->wake_cpu case like:

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 04b62c16fa8c..3d261a4e5b0b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3838,8 +3838,11 @@ static inline bool proxy_needs_return(struct rq *rq, struct task_struct *p)
 	 * will not apply. But if it did, this check is the safe way around
 	 * and would migrate.
 	 */
-	if (task_cpu(p) == p->wake_cpu)
+	if (task_cpu(p) == p->wake_cpu) {
+		/* Begin wait time accounting before marking !is_blocked. */
+		sched_info_enqueue(rq, p);
 		return false;
+	}
 
 	scoped_guard(raw_spinlock, &p->blocked_lock) {
 		/* Task is waking up; clear any blocked_on relationship */
---

Not sure if this solution is ugly or not for calling
sched_info_enqueue() out of the enqueue path :-)

-- 
Thanks and Regards,
Prateek