On Mon, Oct 3, 2022 at 7:18 AM Jens Axboe <axboe@xxxxxxxxx> 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
