public inbox for [email protected]
 help / color / mirror / Atom feed
From: Pavel Begunkov <[email protected]>
To: Jens Axboe <[email protected]>, io-uring <[email protected]>
Subject: Re: [PATCH v2] io_uring: enable toggle of iowait usage when waiting on CQEs
Date: Thu, 20 Mar 2025 10:12:38 +0000	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 3/19/25 01:54, Jens Axboe wrote:
...
>> Do we really want it though? What are you trying to achieve, fixing
>> the iowait stat problem or providing an optimisation option? Because
>> as I see it, what's good for one is bad for the other, unfortunately.
>> A sysctl is not a great option as an optimisation, because with that
>> all apps in the system has either to be storage or net to be optimal
>> in relation to iowait / power consumption. That one you won't even
>> be able to use in a good number of server setups while getting
>> optimal power consumption, even if you own the entire stack.
>>
>> It sounds to me like the best option is to choose which one we want
>> to solve at the moment. Global / sysctl option for the stat, but I'm
>> not sure it's that important atm, people complain less nowadays
>> as well. Enter flag goes fine for the iowait optimisation, but
>> messes with the stat. IMHO, that should be fine if we're clear
>> about it and that the stat part of it can change. That's what
>> I'd suggest doing.
>>
>> The third option is to try to solve them both, but seems your
>> patches got buried in a discussion, and working it around at
>> io_uring side doesn't sound pretty, like two flags you
>> mentioned.
> 
> I'm not digging into that again. Once those guys figure out what they
> want, we can address it on our side.
> 
>> Another option is to just have v2 and tell that the optimisation
>> and the accounting is the same, having some mess on the stat
>> side, and deal with the consequences when the in-kernel semantics
>> changes.
> 
> After thinking about it a bit more, I do think v2 is the best approach.
> And the name is probably fine, IORING_ENTER_NO_IOWAIT. If we at some
> point end up having the ability to control boost and stats separately,
> we could add IORING_ENTER_IOWAIT_BOOST or something. That'll allow you
> to control both separately.

After a private discussion, apparently you do care about the
iowait stat, and there are just too many users that complain
about it and tools that misinterpret it. All that "hint" and
"side effect" discussion of mine doesn't solve that.

I think we do agree that it's a poor interface, but there is
no good alternative, not on the io_uring side, and it's pretty
sad that we're forced into a bad design because the patches
actually solving the problem are blocked for a year now by
sched/cpufreq.

  > What do you think? I do want to get this sorted for 6.15, I feel like
> we've been ignoring or stalling on this issue for way too long.
> 

-- 
Pavel Begunkov


      reply	other threads:[~2025-03-20 10:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-14 18:48 [PATCH v2] io_uring: enable toggle of iowait usage when waiting on CQEs Jens Axboe
2025-03-16  6:57 ` Pavel Begunkov
2025-03-17 14:07   ` Jens Axboe
2025-03-18  6:39     ` Pavel Begunkov
2025-03-18 18:36       ` Jens Axboe
2025-03-18 20:07         ` Pavel Begunkov
2025-03-19  1:54           ` Jens Axboe
2025-03-20 10:12             ` Pavel Begunkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox