On 3/16/25 12:57 AM, Pavel Begunkov wrote: > On 3/14/25 18:48, Jens Axboe wrote: >> By default, io_uring marks a waiting task as being in iowait, if it's >> sleeping waiting on events and there are pending requests. This isn't >> necessarily always useful, and may be confusing on non-storage setups >> where iowait isn't expected. It can also cause extra power usage, by > > I think this passage hints on controlling iowait stats, and in my opinion > we shouldn't conflate stats and optimisations. Global iowait stats > is there to stay, but ideally we want to never account io_uring as iowait. > That's while there were talks about removing optimisation toggle at all > (and do it as internal cpufreq magic, I suppose). > > How about posing it as an optimisation option only and that iowait stat > is a side effect that can change. Explicitly spelling that in the commit > message and in a comment on top of the flag in an attempt to avoid the > uapi regression trap. We'd also need it in the option's man when it's > written. And I'd also add "hint" to the flag name, like > IORING_ENTER_HINT_NO_IOWAIT, as we might need to nop it if anything > changes on the cpufreq side. Having potentially the control of both would be useful, the stat accounting and the cpufreq boosting. I do think the current name is better, though, the hint doesn't really add anything. I think we'd want to have it be clear on one controlling accounting only. Maybe adding both flagts now would be the better choice, except you'd get -EINVAL if you set IORING_ENTER_IOWAIT_BOOST. And then you'd need two FEAT flags, which is pretty damn wasteful. Hmm... -- Jens Axboe
