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

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

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

    Stemming from recent kernel discussions over a hypothetical new system call for reading small files more efficiently, Greg Kroah-Hartman has been working on the readfile() system call and it's looking like it is taking shape well enough to premiere soon in a new mainline kernel release...

    http://www.phoronix.com/scan.php?pag...LE-System-Call

  • #2
    Why does it need a new syscall? Couldn't an ioctl call do it?

    Comment


    • #3
      Originally posted by jacob View Post
      Why does it need a new syscall?
      Because that's the cleanest way to do it. The real question is, why do you have an aversion to new syscalls?

      Originally posted by jacob View Post
      Couldn't an ioctl call do it?
      How would that even work...?

      Comment


      • #4
        Originally posted by JustinTurdeau View Post
        Because that's the cleanest way to do it. The real question is, why do you have an aversion to new syscalls?
        No aversion, but they shouldn't be introduced at whim. Ideally only really new concepts should have new syscalls, new operations on existing object types should be implemented using existing generic interfaces.

        Comment


        • #5
          If "small" is defined as under 4k, and it's handled in a backwards compatible way in libc (maybe make open() a noop, only actually "opening" if the file is large or opened for writing, and close() also potentially a noop), this could be an improvement for 90% of all file accesses.

          Comment


          • #6
            Originally posted by JustinTurdeau View Post

            Because that's the cleanest way to do it. The real question is, why do you have an aversion to new syscalls?



            How would that even work...?
            LoL. y'all been TROLLED! a single ioctl was replaced by open, read/write, close, with the advent of sysfs attrributes.

            Comment


            • #7
              Originally posted by jacob View Post
              Ideally only really new concepts should have new syscalls, new operations on existing object types should be implemented using existing generic interfaces.
              That's nonsense. Adding syscalls for performance reasons is totally legitimate; especially for use cases as common as this one. readv(), writev(), io_submit(), etc. also exist mostly for performance reasons.

              If CPU vendors followed this mentality, we'd only have 10 instructions and everything would run dog slow.
              Last edited by JustinTurdeau; 05-24-2020, 07:15 PM.

              Comment


              • #8
                Originally posted by JustinTurdeau View Post

                That's nonsense. Adding syscalls for performance reasons is totally legitimate; especially for use cases as common as this one.

                If CPU vendors followed this mentality, we'd only have 10 instructions and everything would run dog slow.
                You realise that there is no performance difference whatsoever between ioctl() and a separate syscall, don't you? On a second thought, no, you probably don't.

                An the reason that we don't have dog-slow CPUs is precisely because they have advanced addressing modes and a CISC instruction set that allows generating compact and highly optimised code. RISC (one operation = one instruction) has proven useful for designing small, power efficient and cheap cores, but performance-wise it has comprehensively lost to CISC.

                Comment


                • #9
                  Perhaps also should consider making system calls to work with multiple files/whatever in one call, in batches.
                  Last edited by xpue; 05-24-2020, 07:22 PM.

                  Comment


                  • #10
                    Originally posted by xpue View Post
                    Perhaps also should consider making system calls to work with multiple files/whatever in one call, in batch mode.
                    Here is one I always wanted: be able to pass through a file descriptor. Say you want all input on fd X to be directly forwarded to output fd Y (by the kernel itself, without jumping into and back from user space). The splice() functionality kinda sorta lets you do that but it's clunky and doesn't work in all scenarios.

                    Comment

                    Working...
                    X