Announcement

Collapse
No announcement yet.

Arm Exploring IO_uring For Graphics Drivers For Better Performance & Synchronization

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

  • Arm Exploring IO_uring For Graphics Drivers For Better Performance & Synchronization

    Phoronix: Arm Exploring IO_uring For Graphics Drivers For Better Performance & Synchronization

    The IO_uring asynchronous I/O API for Linux is quite novel and has proven performance benefits. With time IO_uring has been adapted to other areas of the kernel like networking and now with a proposal raised by an Arm graphics driver engineer, it could potentially be adapted for use by Direct Rendering Manager (DRM) kernel graphics drivers...


  • #2
    huh, that was definitely not in my bingo, but very neat

    Comment


    • #3
      The PDF slides link is broken/missing

      Edit: https://indico.freedesktop.org/event...ringforDRM.pdf
      Last edited by Vermilion; 11 October 2024, 03:46 PM.

      Comment


      • #4
        pdf link https://indico.freedesktop.org/event...ringforDRM.pdf

        Comment


        • #5
          unlike io drivers where blocks of data are just copied somewhere else, i consider this pretty interesting to access complex structures containing pointers from kernel-code that could be modified/corrupted by userspace at any time...
          in comparison BPF has several sanity checks and the final (byte)-code is private to the kernel.

          edit: watched the discussion, it seems more akin to passing filedescriptors to the queue. no big issues then... but i dont think that will help performance much?

          ​​​​​​
          ​​​​​​
          Last edited by discordian; 11 October 2024, 03:56 PM.

          Comment


          • #6
            IO_uring go brrrr

            Comment


            • #7
              Does this mean we're now going to have a string of articles about some Axboe-type achieving ever greater numbers of draw calls per second?
              🤩

              Comment


              • #8
                Given my personal experience with IO_uring on the file systems we had it going on... nothing but bad will happen here. We had to disable IO_uring in the end to keep the file system driver from crapping out in production.

                Nothing ever corrupted (thankfully) but we could not get it run stably (past a few weeks at a time).

                Comment


                • #9
                  Originally posted by zexelon View Post
                  Given my personal experience with IO_uring on the file systems we had it going on... nothing but bad will happen here. We had to disable IO_uring in the end to keep the file system driver from crapping out in production.

                  Nothing ever corrupted (thankfully) but we could not get it run stably (past a few weeks at a time).
                  Have you reported the bug?

                  Comment


                  • #10
                    Originally posted by zexelon View Post
                    Given my personal experience with IO_uring on the file systems we had it going on... nothing but bad will happen here. We had to disable IO_uring in the end to keep the file system driver from crapping out in production.

                    Nothing ever corrupted (thankfully) but we could not get it run stably (past a few weeks at a time).
                    Interesting. What programming language/library/framework combination did you use? Was it bare io_uring?

                    I was wondering because depending on what you're using, you don't have to program io_uring directly, just use something that uses io_uring under the hood. That is usually quite easy.
                    Last edited by oleid; 12 October 2024, 03:52 AM.

                    Comment

                    Working...
                    X