Re: [PATCH v2] io_uring: enable toggle of iowait usage when waiting on CQEs

[Pavel Begunkov <asml.silence@gmail.com>]

On 3/17/25 14:07, Jens Axboe wrote:
> 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

It's not the right place to control the stat accounting though,
apps don't care about iowait, it's usually monitored by a different
entity / person from outside the app, so responsibilities don't
match. It's fine if you fully control the stack, but just imagine
a bunch of apps using different frameworks with io_uring inside
that make different choices about it. The final iowait reading
would be just a mess. With this patch at least we can say it's
an unfortunate side effect.
If we can separately control the accounting, a sysctl knob would
probably be better, i.e. to be set globally from outside of an
app, but I don't think we care enough to add extra logic / overhead
for handling it.

> 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

"Hint" tells the user that it's legit for the kernel to ignore
it, including the iowait stat differences the user may see. And
we may actually need to drop the flag if task->iowait knob will
get hidden from io_uring in the future. The main benefit here
is for it to be in the name, because there are always those who
don't read comments.


> 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...
> 

-- 
Pavel Begunkov