This appears to be global across all cpu's. Maybe nr_iowait_tasks
should be accounted on a per-cpu basis, where
(1) If a task sleeps for an io while bound to a cpu it
counts toward the cpu's number of iowait tasks.
(2) iowait time is accounted and reports are generated already
on a per-cpu basis, so there's nothing to do there.
(3) The global statistic does not need to be entirely accurate;
a lockfree approximation by summing across all cpus'
local counters should suffice for global iowait. I also
suspect it will not fluctuate rapidly enough for truly
horribly inaccurate results to occur.
(4) A per-cpu nr_iowait_tasks counter may still well need
to be atomic as other cpu's may be stealing sleeping
tasks purportedly bound to a given cpu at migration
time (in order to prevent going negative) and in that
process altering other cpus' counters.
(5) A flag marking a task as in iowait may well need to be kept
in the task_struct so that at migration time the
appropriate counter adjustments can be made.
(6) Given sufficient cpu affinity in the scheduler the case
where one cpu's counter needs alteration from another
should be relatively uncommon.
The scheduler already participates in keeping per_cpu_user,
per_cpu_system, and per_cpu_nice up-to-date, so it's not
unreasonable to expect its support for per_cpu_iowait.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/