Announcement

Collapse
No announcement yet.

Linux Work Culminating On A "READFILE" Syscall For Reading Small Files Efficiently

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

  • #31
    +1 to Justin.

    Can others stfu about ioctls already? They operate on file descriptors. That means you need to open(), do the ioctl() then close(). What's the fucking difference compared to a normal read?

    The whole point of this syscall is to avoid the open() and close() syscalls.

    Comment


    • #32
      Originally posted by jacob View Post

      This is a wrapper over splice and doesn't work the way I want. You need to wait on in_fd and trigger the transfer for every batch of data (with unnecessary user-kernel trampoline every time), in_fd can't be a socket etc. It works for what it's intended to do, which is a file server, but it doesn't work for something like an on-demand tunnel manager. What I would like is to be able to "attach" an input file descriptor to an output one and have all data simply pass through (for example from socket to socket, or from local socket to inet socket etc.) with no further intervention.
      I see what you mean. I'd like to have that feature too!

      Comment


      • #33
        Originally posted by jacob View Post

        There are many (really MANY) more indirect dispatches involved during the processing of a single call. VFS, LSM, namespace resolution are but a few that pop up on my mind. Adding another one makes exactly zero measurable difference in processing performance but if it means having a cleaner and more coherent kernel interface I'm all for it.
        So if you go from 50 to 51 dispatches, that's still not zero cost. It's a 2% additional overhead, wasted just for the heck of it.

        Comment


        • #34
          IMHO this is really bad system call and kernel ABI design. Pointless endeavour for non mition critical / high performance use case. Instead what would be amazing would be vectored / bundled system calls that would also be useful for actual high performance stuff, you know databases, fileserver and fun stuff like that: https://www.youtube.com/watch?v=84Uyh3KwY-w

          Comment


          • #35
            Originally posted by rene View Post
            Instead what would be amazing would be vectored / bundled system calls that would also be useful for actual high performance stuff
            How is that different than io_uring?

            Comment


            • #36
              Originally posted by coder View Post
              How is that different than io_uring?
              certainly much simpler when you look at the io_uring code, synchronous, and last but not least work at all, as uring currently does not allow to re-use return values of previous syscalls, e.g. opened file-descriptors for the next systemically.

              Comment

              Working...
              X