Re: [PATCH v3] sched/stats: Fix run_delay over-count for migrated sched_delayed tasks

[albin_yang@163.com]

Hi Peter,

On Tue, 22 Sep 2026 12:55:22 +0200, Peter Zijlstra wrote:
> Will we not have a similar problem with proxy exec? That is, would
> t->is_blocked be more appropriate?

Yes, there is a similar issue: proxy_migrate_task() re-attaches a blocked
donor via activate_task() without ENQUEUE_RESTORE -- a fake enqueue that
should not update last_queued. Thanks to Kayra for confirming this and for
the task_is_blocked() idea.

But t->is_blocked can't gate it. In ttwu_runnable(), the real wakeup of a
delayed task does its enqueue_task(ENQUEUE_DELAYED) inside the
if (p->is_blocked) branch, and is_blocked is only cleared afterwards in
ttwu_do_wakeup(). So !is_blocked would suppress exactly the re-arm this
patch relies on, and run_delay would never be accounted.

task_is_blocked() does look usable for the proxy case: every waker clears
blocked_on before waking the task (mutex handoff, ww_mutex die/wound,
proxy_needs_return), so it should not be set on a real wakeup enqueue. But
it cannot replace se.sched_delayed -- a delayed sleeper has no blocked_on at
all -- so it would have to be an additional condition rather than a
substitute.

Before adding that I would like to reproduce the proxy case and confirm what
the donor's run_delay should look like: whether the time it spent blocked on
the mutex ought to be dropped like a delayed sleep, or accounted somehow.

Please shed some light on how the proxy case could be dealt with, or should
this patch only focus on the delayed case?

Thanks,
Wei Yang