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

[Christian Loehle <christian.loehle@arm.com>]

On 10/15/26 08:35, Peter Zijlstra wrote:
> On Wed, Oct 14, 2026 at 02:17:52PM +0100, Christian Loehle wrote:
> 
>>> 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.
> 
> \o/
> 
>> FWIW the remaining aggregated nr_iowait users seem to be accounting/reporting.
>> (cpufreq still uses it, but it comes directly from p->in_iowait).
> 
> I see: get_cpu_iowait_time_us() using nr_cpuwait_cpu(), which in turn is
> used for both thermal and cpufreq.

thermal uses it with io_is_busy=0, so that's okay, ondemand has it sysfs-exposed
with a default of 0 except for 
	return (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
		boot_cpu_data.x86_vfm >= INTEL_PENTIUM_PRO);

:/

If that were the only users I'm sure there would be ways around it though.

> 
>> 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.
> 
> Right.
> 
>> 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...
> 
> Given the exposure in /proc I'm not sure we can *ever* fully get rid of
> the per-cpu usage of iowait, but yeah, reducing in-kernel consumers of
> this number might be somewhat feasible.