IO_uring Adding Support For Vectored FUTEX Waits In Linux 6.6

[phoronix]

Phoronix: IO_uring Adding Support For Vectored FUTEX Waits In Linux 6.6

With the upcoming Linux 6.6 cycle another exciting change was recently queued up within the block subsystem's "for-next" branch: IO_uring futex/futexv support...

https://www.phoronix.com/news/Linux-6.6-IO_uring-FUTEX

[guspitts]

Is IO_uring slowly becoming the new system call interface? Only one system call through which all the others are funneled? (not making a judgement call, simply pondering the evolution of this API).

[dragorth]

I don't know that all will go through IO_uring, but I would bet anything that is bandwidth constrained and is trying to avoid locks is a candidate. Something like keyboard input probably is not a good candidate, whereas maybe something in the graphics/ai stack that is pushing large amounts of data is.

[discordian]

If you build an ui for io-uring, how would it look like?

If it ends up looking like Factorio, it should pass as game.

[F.Ultra]

Is IO_uring slowly becoming the new system call interface? Only one system call through which all the others are funneled? (not making a judgement call, simply pondering the evolution of this API).

probably not, the complexity and the overhead makes it a bad option for calling just a few syscalls, it really only becomes the better solution if you have to call lots of syscalls simultaneously. AFAIK it also handles the actual calls in thread pools so the latency of single syscalls are increased, not to mention that those threads compete with any application doing their own thread pools, especially if they are a bit more advanced with thread affinity and so on.

[zcansi]

AFAIK it also handles the actual calls in thread pools so the latency of single syscalls are increased, not to mention that those threads compete with any application doing their own thread pools, especially if they are a bit more advanced with thread affinity and so on.

This is only a "fallback" for when the operation can't be handled without blocking and there is no native asynchronous notification implemented for that subsystem. In the beginning most things were using this thread pool fallback but they have been actively reducing that.

[F.Ultra]

This is only a "fallback" for when the operation can't be handled without blocking and there is no native asynchronous notification implemented for that subsystem. In the beginning most things were using this thread pool fallback but they have been actively reducing that.

Good to know, thanks!

[microcode]

Is IO_uring slowly becoming the new system call interface? Only one system call through which all the others are funneled? (not making a judgement call, simply pondering the evolution of this API).

Yeah. io_uring is just better than most syscalls; it still has to mature, and it has been exposing footguns in the internal kernel interfaces (which is why Google has disabled it in their kernels).

If io_uring was the original interface for most syscalls, it would have been for the better.

There are certain limited circumstances where it would increase the memory requirements of basic programs, or moderately increase latency for certain operations if used incorrectly, but outside of these marginal issues it is just the better way to do continuous io with more than a couple FDs.