Announcement

Collapse
No announcement yet.

New readfile() System Call Under Review For Reading Small~Medium Files Faster

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

  • #21
    Originally posted by F.Ultra View Post

    There is no size limit, the mentioning of "small and medium" is because for smaller files the overhead of 3 syscalls is way larger than the actual time it takes to read the contents of the file and that is where this new syscall gives a performance boost, if it's convenience you are after then it's a boost regardless of file size.
    Ohh, that changes things! Thank you for that reply!
    That means that any file you'd previously read into memory could now use this syscall. Or rather, should! As it only give you a net win.

    Now i kinda hope that toolkits (say Qt/GTK) are going to provide support for this too!

    Those places that already did open/read themselves with smarter memory usage (like streaming) should just stay as is i think?

    Comment


    • #22
      Originally posted by coder View Post
      IOPS is Io Operations Per Second. You can increase them either by overlapping more operations or decreasing the time between successive operations. This addresses only the latter, though still improves performance (which, again, is their reason for doing it)

      If you also want the former, then you can simply use it with io_uring to queue up multiple readfile() operations.

      So, you can have your cake and eat it!
      Just a note: Reducing 3 syscalls into 1 most likely won't increase uncached IOPS: HDD has about 100 random IOPS, SSD is about 10000 random IOPS (except for 3D XPoint), a getpid() syscall is about 100 nanoseconds and 1/100ns = 10 million no-operation "IOPS". 10e6 is 1000 times larger than 10e3.

      It would be nice to have benchmarks of the readfile() syscall, so that we do not need to make wild guesses.

      I agree about the use of asynchronous I/O.
      Last edited by atomsymbol; 07-05-2020, 11:49 PM. Reason: Add last sentence

      Comment


      • #23
        Originally posted by atomsymbol View Post
        Just a note: Reducing 3 syscalls into 1 most likely won't increase uncached IOPS: HDD has about 100 random IOPS, SSD is about 10000 random IOPS (except for 3D XPoint), a getpid() syscall is about 100 nanoseconds and 1/100ns = 10 million no-operation "IOPS". 10e6 is 1000 times smaller than 10e3.
        Good point.

        On what CPU were those measurements taken? Did you have any mitigations disabled? Not that it would change the overall impact on IOPS (except perhaps with Optane), but it'd be good to know.

        Comment


        • #24
          Originally posted by coder View Post
          On what CPU were those measurements taken? Did you have any mitigations disabled?
          Ryzen 3000 desktop. Mitigations disabled.

          Comment


          • #25
            Originally posted by atomsymbol View Post

            Ryzen 3000 desktop. Mitigations disabled.
            then your results are worth nothing, sorry
            While i agree with disabling mitigations. Everyone should do that! The security paranoia went too far on that front. The super majority will just update their system and don't bother adding boot flags to disable them. Distributions also likely won't add them..

            You're also comparing roughly the slowest medium for these days (spinning drives). Lots of people nowadays have an NVMe as their daily driver. That will significantly change your results. Still a syscall is likely going to be a very minor part of the whole operation that was executed. So for one call that won't give any notable performance difference i suppose. But things might change if you multiply it by tens of thousands.. Remember, a simple action like showing a thumbnail probably executes a handful of syscalls now (stat it, read, open, close, extended attributes, ....).

            Comment


            • #26
              Just for fun.
              I did an strace -c on a folder opened in dolphin. The folder only contains 2048 jpg files (wallpaper sizes of full hd resolution)

              Without thumbnail presentation (they are generated before this run)
              28114 syscalls!
              Look here for the full output: https://p.sc2.nl/TWKfB

              With thumbnail presentation (note that dolphin does that for only those that are in your view, so this is even optimized)
              39984 syscalls!
              Look here for the full output: https://p.sc2.nl/un8r5

              Keep in mind that this is Dolphin. Thus it uses KIO. That means you don't see the actual opening of the thumbnail files in strace as that's done in IO slave handlers in other processes. Having said that, now i'm REALLY curious what those statx calls, read and writes do and where they come from. It's also interesting to see so many errors! I think i have to investigate a bit there to figure out what's going on.

              Note the high time percentage of futex too. There's room for improvements i think. But does it matter? This many stat calls and dolphin still starts in mere milliseconds and you're off browsing the files. In other terms, reducing stat calls here to the bare minimum is likely not going to result in any perceived speedup. But it will likely result in the CPU being done (much) faster thus for energy savings this is beneficial. If it's worth it is another matter entirely

              Comment


              • #27
                Originally posted by markg85 View Post
                then your results are worth nothing, sorry
                The results aren't that far from generic (mitigations on) settings on AMD CPUs. Numbers for Intel might be different. Future/newer Intel CPUs will resolve or avoid the security issues in hardware, so the performance degradation per syscall on Intel CPUs is just temporary.

                Question: If it wasn't an issue not to have the readfile() Linux syscall on 386/486 CPUs in the 90-ties, then why is it an issue now in year 2020?

                Originally posted by markg85 View Post
                While i agree with disabling mitigations. Everyone should do that! The security paranoia went too far on that front. The super majority will just update their system and don't bother adding boot flags to disable them. Distributions also likely won't add them..

                You're also comparing roughly the slowest medium for these days (spinning drives). Lots of people nowadays have an NVMe as their daily driver. That will significantly change your results.
                Just a note: SATA and NVMe have very similar random 4K read IOPS at queue depth 1 (about 10000 IOPS) because it (presumably) is limited by the technology and not limited by SATA speeds.

                Just a 2nd note: Many people are archiving data and storing videos on HDDs, not SSDs, because of capacity and because of cost per terabyte.

                Originally posted by markg85 View Post
                Still a syscall is likely going to be a very minor part of the whole operation that was executed. So for one call that won't give any notable performance difference i suppose. But things might change if you multiply it by tens of thousands.. Remember, a simple action like showing a thumbnail probably executes a handful of syscalls now (stat it, read, open, close, extended attributes, ....).

                Comment


                • #28
                  Originally posted by markg85 View Post
                  ... But things might change if you multiply it by tens of thousands.. Remember, a simple action like showing a thumbnail probably executes a handful of syscalls now (stat it, read, open, close, extended attributes, ....).
                  I hope you do realize that there exist far better [research] methods of how to increase performance of kernel-userspace transitions, by a factor of 10 at least compared to what Linux is currently doing.
                  Last edited by atomsymbol; 07-06-2020, 08:00 AM. Reason: Bold typeface is too much, lets just use underlined font

                  Comment


                  • #29
                    Originally posted by atomsymbol View Post

                    I hope you do realize that there exist far better [research] methods of how to increase performance of kernel-userspace transitions, by a factor of 10 at least compared to what Linux is currently doing.
                    Enlighten me
                    As far as i know, io_uring is the best there is going to be. And it won't even come close to a 10x improvement (more like 0.2x) the main difference being fully async in nature.
                    So i'm really curious to know your 10x claim. Do back it up by an article that shows the performance supremacy.

                    Comment


                    • #30
                      Originally posted by markg85 View Post
                      Do back it up by an article that shows the performance supremacy.
                      NaCl.

                      Comment

                      Working...
                      X