public inbox for [email protected]
 help / color / mirror / Atom feed
From: Linus Torvalds <[email protected]>
To: Jens Axboe <[email protected]>, Dylan Yudaken <[email protected]>
Cc: io-uring <[email protected]>
Subject: Re: [GIT PULL] io_uring updates for 6.1-rc1
Date: Fri, 7 Oct 2022 09:07:45 -0700	[thread overview]
Message-ID: <CAHk-=wg1RzrA5dq_9RTz-mhxOPmy7nFap2NiS-Kz6KwpUuDMmg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>

On Mon, Oct 3, 2022 at 7:18 AM Jens Axboe <[email protected]> wrote:
>
> - Series that adds supported for more directly managed task_work
>   running. This is beneficial for real world applications that end up
>   issuing lots of system calls as part of handling work.

While I agree with the concept, I'm not convinced this is done the right way.

It looks very much like it was done in a "this is perfect for benchmarks" mode.

I think you should consider it much more similar to plugging (both
network and disk IO). In particular, I think that you'll find that
once you have random events like memory allocations blocking in other
places, you actually will want to unplug early, so that you don't end
up sleeping with unstarted work to do.

And the reason I say this code looks like "made for benchmarks" is
that you'll basically never see those kinds of issues when you just
run some benchmark that is tuned for this.  For the benchmark, you
just want the user to control exactly when to start the load, because
you control pretty much everything.

And then real life happens, and you have situations where you get
those odd hiccups from other things going on, and you wonder "why was
no IO taking place?"

Maybe I'm misreading the code, but it looks to me that the deferred
io_uring work is basically deferred completely synchronously.

I've pulled this, and maybe I'm misreading it. Or maybe there's some
reason why io_uring is completely different from all the other
situations where we've ever wanted to do this kind of plugging for
batching, but I really doubt that io_uring is magically different...

                  Linus

  reply	other threads:[~2022-10-07 16:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03 14:18 [GIT PULL] io_uring updates for 6.1-rc1 Jens Axboe
2022-10-07 16:07 ` Linus Torvalds [this message]
2022-10-07 16:30   ` Jens Axboe
2022-10-08 18:12     ` Dylan Yudaken
2022-10-07 17:00 ` pr-tracker-bot

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 \
    --in-reply-to='CAHk-=wg1RzrA5dq_9RTz-mhxOPmy7nFap2NiS-Kz6KwpUuDMmg@mail.gmail.com' \
    [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