Re: [PATCH] sched: Account blkio delay independently of delayed dequeue

[Zhan Xusheng <zhanxusheng1024@gmail.com>]

On 10/14/26 17:12, Christian Loehle wrote:
> Start accounting in try_to_block_task(), when the current task commits
> to blocking, before delayed dequeue or proxy execution can retain it on
> the runqueue. End accounting when clearing is_blocked, including queued
> wakeups and the proxy execution paths that let the current task continue.

This is the right place, and it subsumes my patch. Please drop mine
rather than queue both.

try_to_block_task() has only one caller, __schedule(), which passes prev,
and prev is rq->curr there. So @p is current, the argument-less
delayacct_blkio_start() is correct once the call lives there, and the
signature change I proposed is unnecessary.

The two also conflict: my patch rewrites the sched.h line yours deletes,
so applying mine first makes your sched.h hunk fail, and the new call in
try_to_block_task() would not compile against the changed prototype.

Reviewed-by: Zhan Xusheng <zhanxusheng@xiaomi.com>

One question. rq->nr_iowait stays in __block_task(), so the two now
measure different intervals: blkio delay from the commit to block,
nr_iowait from the actual dequeue. A task woken while still delayed is
accounted a blkio delay but was never counted in nr_iowait, so
procs_blocked in /proc/stat and the iowait time derived from
nr_iowait_cpu() still lose that window. The counter stays balanced,
because such a wakeup returns through ttwu_runnable() and never reaches
the atomic_dec() in ttwu_do_activate(), so this is not a leak. Is leaving
nr_iowait behind deliberate, or a follow-up?

Thanks,
Zhan Xusheng