Announcement

Collapse
No announcement yet.

IO_uring Adding Support For Vectored FUTEX Waits In Linux 6.6

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • IO_uring Adding Support For Vectored FUTEX Waits In Linux 6.6

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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).

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          Originally posted by guspitts View Post
          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.

          Comment


          • #6
            Originally posted by F.Ultra View Post
            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.

            Comment


            • #7
              Originally posted by zcansi View Post

              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!

              Comment


              • #8
                Originally posted by guspitts View Post
                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.
                Last edited by microcode; 28 August 2023, 12:36 PM.

                Comment

                Working...
                X