Re: [PATCH v1] sched/cputime: Preserve iowait accounting across waking interrupts in dyntick-idle

[Christian Loehle]

On 10/14/26 13:49, Peter Zijlstra wrote:
> On Wed, Oct 14, 2026 at 01:52:58AM +0000, Wei Gao wrote:
>> In liburing's test suite, the test/iowait.t test case intermittently fails
>> with:
>>     iowait diff too small: 48
>>     test 1 failed
>> on tickless systems where IRQ time accounting (CONFIG_IRQ_TIME_ACCOUNTING)
>> is not enabled.
>>
>> Commit 7198e3927a14 ("sched/cputime: Handle idle irqtime gracefully")
>> optimized dyntick-idle cputime accounting by avoiding pausing idle
>> accounting on IRQ entry when IRQ time accounting is disabled.
>>
>> However, this causes iowait time to be erroneously accounted as
>> CPUTIME_IDLE if the task waiting for I/O is woken up inside the interrupt
>> handler (such as the 1-second timeout hrtimer in liburing's test/iowait.t):
>>
>> 1. In test/iowait.t, a read request is submitted on an empty pipe and
>>    io_uring_wait_cqe_timeout() is called with a 1-second timeout. Because
>>    current->in_iowait is set, rq->nr_iowait on the CPU is incremented
>>    to 1. When the CPU enters tickless idle, the periodic scheduler tick
>>    is stopped.
>> 2. When the 1-second timeout expires, the hrtimer interrupt fires.
>>    Because irqtime is disabled, kcpustat_irq_enter() does not pause idle
>>    accounting.
>> 3. Inside the interrupt handler, io_cqring_timer_wakeup() calls
>>    wake_up_process(). In ttwu_do_activate(), waking up the task immediately
>>    decrements rq->nr_iowait from 1 to 0 before the CPU has exited idle.
>> 4. When the CPU returns from the interrupt and calls tick_nohz_idle_exit()
>>    -> kcpustat_idle_stop() to settle the elapsed tickless idle duration,
>>    it checks:
>>        iowait = nr_iowait_cpu(smp_processor_id()) > 0;
>>    Because rq->nr_iowait was already decremented by ttwu_do_activate(),
>>    this evaluates to false. As a result, the entire 1-second idle duration
>>    spent waiting for I/O is credited to CPUTIME_IDLE instead of
>>    CPUTIME_IOWAIT, causing diff < 50 and failing the test.
>>
>> Fix this by checking nr_iowait_cpu() in kcpustat_irq_enter(). If the CPU is
>> currently in iowait, pause and settle the elapsed time to CPUTIME_IOWAIT
>> before the interrupt handler runs. On kcpustat_irq_exit(), resume
>> accounting if it was paused.
> 
> Using nr_iowait_cpu() is fundamentally never a fix. It is rolling a dice
> and liking random numbers. See the comment that goes with that function.
> 
Speaking of, that comment is stale, menu doesn't use that heuristic anymore.
FWIW the remaining aggregated nr_iowait users seem to be accounting/reporting.
(cpufreq still uses it, but it comes directly from p->in_iowait).
Given they are exported (/proc/stat procs_blocked and something in s390) I don't
see how we can remove this entirely but at least nr_iowait_cpu() as opposed
to cpu_has_iowait() could be refactored. The issues are obviously the same still.
I'll send a patch.

Peter, if you see a path to ever retire iowait (or at least the CPU iowait for now),
I'm more than happy to sink some time into it...