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

[Christian Loehle]

On 10/15/26 03:59, Zhan Xusheng wrote:
> 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@xxxxxxxxxx>
> 
> 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?

Your observation is correct.
First of all we're hoping that /proc/stat isn't observed at such granularity
to matter, but that's not really a good enough reason to leave it behind.
AFAICS we would need to start tracking iowait_cpu in task_struct then?
I'm fine with that and can send a follow-up, I guess Peter feel free to take
whatever you prefer.

(Given the update interval of /proc/stat and the expected delayed-dequeue time
 not 'fixing' it is also an option IMO. I don't see why we need to guarantee
that the blkio delay and nr_iowait need to track the exact same transitions.)