Announcement

Collapse
No announcement yet.

READFILE System Call Rebased For More Efficient Reading Of Small Files

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

  • #41
    Originally posted by oiaohm View Post

    This is still you not understanding the problem. Readfile syscall does not just gain because 3 syscalls come one. Remember a normal open syscall has to add 1 to the ulimit file count and close subtracts 1 the Readfile syscall can skip this. Remember current ulimit values have to be shared so changing them can be quite performance costly.
    You are kidding me, optimizing one atomic add away? Lol

    Small file reads are in fact used a lot even in a sysvinit. You think PIDfile checking to prevent starting a service twice. There are quite a few small file usage presure points once you go looking for them. These are all hidden in utility programs that are used over and over again. Systemd with more complex cgroup process management is reading more small files. The effects of ulimit changes having to be shared also gets bigger. Think systemd is going to be used by KDE and Gnome around every started application.

    The reality here is a straight up vectored syscall will not deal with the ulimit issue caused by open and close because you have it performing a normal syscall. A vectored syscall to properly handle error events is going to require setup so you cannot be sure u_ioring will be any worse than doing a vectored syscall due to how heavy doing proper error handing is going to be.
    While optimizing a ulimit addition is already laughable, many probably consider it correct operation if your ulimit is 256 and your 257'th readfile() would fail as an open would.

    Also error handling or a vectored syscall for the normal success case is as simple as for one read or open: it it returned success all vectored calls succeeded. Even for the error case it is not much harder, and could be abstracted in a libc readfile shim.

    Yes readfile vs a vector syscall doing (open,read,close) the readfile is going to be faster because the vectored is going to have allow for the possibility it does not contain a close so change ulimit on open or close or process what vectored syscall has been passed to attempt to work out if it does not have to do ulimit change.

    Vectored syscall is more flex able but it that flexibility that comes back and kicks you where it hurts with the open read close problem. Dealing with that flexibility issues does come with its own overhead problem.

    Really I would like to see a writefile as well.
    See how vsyscall for any sequence of open, write, close would be handy, too? ;-)

    Those asking for a readfile syscall in Linux have correctly looked at the problem. Yes just like indepe said if you wanted vectored syscalls having readfile syscall is not mutually exclusive. You have failed to notice the all advantages the readfile syscall gets its reduction in syscalls it also reduction in atomic locking on ulimit a valve due to not needing to increase and decrease the file open count. Yes this is another bit of error handling how to handle the problem of max open file count.
    Atomic locking of ulimit, even my i486 and Sgi Octane are still laughing about that one. Man that was a good one. lol ;-)

    For a everything is a file operating system having a open read close and open write close as single syscalls has their place.
    OMG no! Thanks god you are not kernel developer ;-) But see how flexible a simple vsyscall for any such syscall would be?

    Comment


    • #42
      Originally posted by rene View Post
      You are kidding me, optimizing one atomic add away? Lol

      Atomic locking of ulimit, even my i486 and Sgi Octane are still laughing about that one. Man that was a good one. lol ;-)

      OMG no! Thanks god you are not kernel developer ;-) But see how flexible a simple vsyscall for any such syscall would be?
      Really with this answer I can understand why your idea is being rejected by kernel developers. The overhead of atomic operation overhead increases as your core count goes up. A i486 that a single core or a Sgi Octane that at max is only 2 core is not going to have much of a atomic operation overhead.

      Yes you got it wrong its 2 atomic operations removed. 1 add that is the open and 1 subtract that is the close. I did write both. So readfile takes away 2 syscalls and two atomic operations.

      Originally posted by rene View Post
      While optimizing a ulimit addition is already laughable, many probably consider it correct operation if your ulimit is 256 and your 257'th readfile() would fail as an open would.
      With the atomic memory operations this has very little overhead. Its your value changing that causes overhead with atomic operations. So a ulimit of 256 and you are attempting 257 file this could get interesting. readfile could technically be allowed to proceed because its not increase number of actively open files. This kind of allowance is not possible with the vectored syscall allowance.

      Think for reading system setting values from sysfs or procfs does it really make sense to be increasing ulimit count if you are not keeping those files open for some reason.

      Originally posted by rene View Post
      See how vsyscall for any sequence of open, write, close would be handy, too? ;-)
      Absolute not a much as a proper writefile command. This is because you have ignored the overhead of atomic operations. Yes your response show you did not understand that a atomic operation cost on a modern 64 core 128 thread cpu is way worse than i486 that is a single thread or a Sgi Octane that at best is 2 threads.

      rene you are being absolute clueless. Vectored syscall idea has major limitations. A direct syscall for readfile and writefile makes more sense today than it did in past due to the increasing number of cores resulting in the increased cost of locking and atomic operations by having more core/threads to keep on the same page.

      Think about it you have 128 threads in a process all doing a readfile operation removing ulimit alteration from that means those operations can be processed inside each thread of the cpu without having to check with any other core if doing this is fine.

      Writefile does get trick again because you do have to have a atomic operation for altering a value in procfs and sysfs but this is from 3 atomic operations to 1.

      Comment


      • #43
        Originally posted by oiaohm View Post

        Really with this answer I can understand why your idea is being rejected by kernel developers. The overhead of atomic operation overhead increases as your core count goes up. A i486 that a single core or a Sgi Octane that at max is only 2 core is not going to have much of a atomic operation overhead.

        Yes you got it wrong its 2 atomic operations removed. 1 add that is the open and 1 subtract that is the close. I did write both. So readfile takes away 2 syscalls and two atomic operations.


        With the atomic memory operations this has very little overhead. Its your value changing that causes overhead with atomic operations. So a ulimit of 256 and you are attempting 257 file this could get interesting. readfile could technically be allowed to proceed because its not increase number of actively open files. This kind of allowance is not possible with the vectored syscall allowance.

        Think for reading system setting values from sysfs or procfs does it really make sense to be increasing ulimit count if you are not keeping those files open for some reason.



        Absolute not a much as a proper writefile command. This is because you have ignored the overhead of atomic operations. Yes your response show you did not understand that a atomic operation cost on a modern 64 core 128 thread cpu is way worse than i486 that is a single thread or a Sgi Octane that at best is 2 threads.

        rene you are being absolute clueless. Vectored syscall idea has major limitations. A direct syscall for readfile and writefile makes more sense today than it did in past due to the increasing number of cores resulting in the increased cost of locking and atomic operations by having more core/threads to keep on the same page.

        Think about it you have 128 threads in a process all doing a readfile operation removing ulimit alteration from that means those operations can be processed inside each thread of the cpu without having to check with any other core if doing this is fine.

        Writefile does get trick again because you do have to have a atomic operation for altering a value in procfs and sysfs but this is from 3 atomic operations to 1.
        Betriebssystem Design nicht den Leyen überlassen ;-)

        Comment


        • #44
          Originally posted by rene View Post
          I have news for you: readfile() will not affect the speed of which shell scripts and especially non-builtin commands execute at all.
          Not overnight, of course. Stuff has to start using it, first.

          Comment


          • #45
            Originally posted by rene View Post
            Betriebssystem Design nicht den Leyen überlassen ;-)
            I've had about enough of your patronizing attitude. If you really think so much less of us, then why bother trying to keep cramming your idea down our throats? You have a convenient explanation for us rejecting it, so your ego should remain intact... unless maybe the one you're really trying to convince that your right is yourself.

            Either way, this is going nowhere. We understand your idea and we don't accept it. But, we're just inconsequential commenters on a news site, remember? So, let's live to see another day... when we can fight over something different. Who knows, maybe we'll even agree? I'm sure there must be a lot we can all agree on, too.

            Comment


            • #46
              Originally posted by rene View Post

              I can't follow, let alone read all random stuff discussed on each mailing list. However, all of my proposals would just work with your examples. Of course they would return which syscall were run and their respective error codes. So depending on which proposal you look at, the user space app would either get to know read() failed and close() was not executed and thus do it if needed, or for my other proposal the app would mark open to abort on fail, and read and close not. In either case there user space app would get a vector of return values. As simple as that and certainly more universal than the bloddy readfile() nobody really needs nor asked for and the "open with fixed fd" for io_uiring proposal. I wonder how that should scale and work flawlessly in a sophisticated application.

              It is not rocket science, and certainly all way more generally usable than readfile(). Sigh.
              Low IQ rene strikes again. Dunning-Kruger is a hell of a drug.

              Comment


              • #47
                Originally posted by rene View Post
                Betriebssystem Design nicht den Leyen überlassen ;-)
                Operating system design is not left to the Leyen. This is a being nice and insulting while writing in way most people would not notice.


                Yes most english people writing would not know that Leyen is a particular german Nobel family. To be correct one reading of this could be a person with absolute authority remember items like Linux kernel has what is called dictators for life that are people with absolute authority. So like it not a lot of operating system design is left what could be called a noble class.

                The not as insulting version and more correct is:
                Operating system design is not left to the layman. Or the german. Betriebssystem Design nicht den laie überlassen.
                Even these are not 100 percent correct either. When you play in unikernel you learn very quickly some are made by laymen who have no clue what they are really doing yet they are used in production.

                Yes that is layman meaning "a person without professional or specialized knowledge in a particular subject.".

                Really rene you need to take a close look at yourself you could not even write a single line of german here that was correctly aligned to reality.

                Yes I do read german I could have written a answer in german as well but this is a english forum show some respect and don't attempt to be insulting by hiding it in german some of us here will spot it rene and know exactly what it is. I first run across with how expensive atomic operations could be is when I was running a 4096 core system that was almost 2 decades ago. Like it or not I am not a layman on why readfile makes sense and vectored syscalls don't in many cases that readfile will be used. Rene you have been lacking the specialised knowledge remember a lot of the Linux kernel developers are like me who have worked with 4096 core systems or bigger so they have a different point of view.

                Readfile syscall is very different once you get into implement to a vectored syscall and comparing the the results on system operations. There has been call for something like a readfile syscall in Linux as early as the year 2000 by groups running supercomputers with massive number of cores due to the atomic operation costs.

                https://en.wikipedia.org/wiki/Parall...Gustafson's_la w

                Atomic operations are covered under Amdahl's law.


                The reality is atomic operations are not 100 percent parallel. Small increases in how much can be done in parallel do have very big effects on performance as your thread/core count goes up. You have to think epyc dual core servers these days are 256 threads. The difference at 1 or 2 threads cpu system on how parallel stuff is basically almost not measurable. Yet even at 256 a 0.1 percent improvement quite a bit of gain.

                Yes Amdahl's law also explains why a syscall like readfile did not make sense historically there was not the performance gain on the table because systems were not parallel enough to have a issue with atomic operations. Yes back on a single core/dual core system your arguement rene for vectored syscall over readfile makes some sense problem the systems we use today are increasing core count and thread count with how parallel things are coming a larger and larger factor. On 32/64 core/thread systems there is more performance gain in the 2 avoided atomic operations with readfile than the 2 syscall savings.

                Readfile is not just saving syscalls readfile saving atomic operations. Going forwards there is going to have to be more consideration in OS design on how have less not parallel stuff because of increasing core and thread count.

                OS design method has had to change with the hardware like it or note rene the way you were pushing vectored syscalls was not taking the modern need for parallel operations into account and how that makes reducing things like atomic operations important.

                Rene error handling is a problem in the vectored designs put forwards in designs so far. Lack of saving in atomic operations and other features that are not fully parallel is another problem with vectored syscalls so far. Remember reading the contents of sysfs or procfs if you have 4096 thread system in theory if the operations you use don't use atomics all 4096 threads could be reading all those files at the same time so true 100 percent parallel where the current syscalls and your proposed vectored syscalls cannot achieve this but proposed readfile syscall can.

                Comment


                • #48
                  Originally posted by oiaohm View Post

                  Operating system design is not left to the Leyen. This is a being nice and insulting while writing in way most people would not notice.


                  Yes most english people writing would not know that Leyen is a particular german Nobel family. To be correct one reading of this could be a person with absolute authority remember items like Linux kernel has what is called dictators for life that are people with absolute authority. So like it not a lot of operating system design is left what could be called a noble class.

                  The not as insulting version and more correct is:
                  Operating system design is not left to the layman. Or the german. Betriebssystem Design nicht den laie überlassen.
                  Even these are not 100 percent correct either. When you play in unikernel you learn very quickly some are made by laymen who have no clue what they are really doing yet they are used in production.

                  Yes that is layman meaning "a person without professional or specialized knowledge in a particular subject.".

                  Really rene you need to take a close look at yourself you could not even write a single line of german here that was correctly aligned to reality.

                  Yes I do read german I could have written a answer in german as well but this is a english forum show some respect and don't attempt to be insulting by hiding it in german some of us here will spot it rene and know exactly what it is. I first run across with how expensive atomic operations could be is when I was running a 4096 core system that was almost 2 decades ago. Like it or not I am not a layman on why readfile makes sense and vectored syscalls don't in many cases that readfile will be used. Rene you have been lacking the specialised knowledge remember a lot of the Linux kernel developers are like me who have worked with 4096 core systems or bigger so they have a different point of view.

                  Readfile syscall is very different once you get into implement to a vectored syscall and comparing the the results on system operations. There has been call for something like a readfile syscall in Linux as early as the year 2000 by groups running supercomputers with massive number of cores due to the atomic operation costs.

                  https://en.wikipedia.org/wiki/Parall...afson's_la w

                  Atomic operations are covered under Amdahl's law.


                  The reality is atomic operations are not 100 percent parallel. Small increases in how much can be done in parallel do have very big effects on performance as your thread/core count goes up. You have to think epyc dual core servers these days are 256 threads. The difference at 1 or 2 threads cpu system on how parallel stuff is basically almost not measurable. Yet even at 256 a 0.1 percent improvement quite a bit of gain.

                  Yes Amdahl's law also explains why a syscall like readfile did not make sense historically there was not the performance gain on the table because systems were not parallel enough to have a issue with atomic operations. Yes back on a single core/dual core system your arguement rene for vectored syscall over readfile makes some sense problem the systems we use today are increasing core count and thread count with how parallel things are coming a larger and larger factor. On 32/64 core/thread systems there is more performance gain in the 2 avoided atomic operations with readfile than the 2 syscall savings.

                  Readfile is not just saving syscalls readfile saving atomic operations. Going forwards there is going to have to be more consideration in OS design on how have less not parallel stuff because of increasing core and thread count.

                  OS design method has had to change with the hardware like it or note rene the way you were pushing vectored syscalls was not taking the modern need for parallel operations into account and how that makes reducing things like atomic operations important.

                  Rene error handling is a problem in the vectored designs put forwards in designs so far. Lack of saving in atomic operations and other features that are not fully parallel is another problem with vectored syscalls so far. Remember reading the contents of sysfs or procfs if you have 4096 thread system in theory if the operations you use don't use atomics all 4096 threads could be reading all those files at the same time so true 100 percent parallel where the current syscalls and your proposed vectored syscalls cannot achieve this but proposed readfile syscall can.
                  your correction puts interpreting words into my mouth that I internally did not write. I wrote Leyen for a good reason lol.

                  Also repeating false claims all day long do not make them more true. I guess there is a reason Linus Torvalds comments on real world tech and not Phoronix. It is probably time to ignore this News plumbing website, ...
                  Last edited by rene; 07 April 2021, 03:13 AM.

                  Comment


                  • #49
                    Originally posted by rene View Post
                    I guess there is a reason Linus Torvalds comments on real world tech and not Phoronix. It is probably time to ignore this News plumbing website, ...
                    Your words betray your own feelings. If you truly held us in such low regard, why even bother to insult us? I think you're really just trying to convince yourself that we're wrong.

                    Comment


                    • #50
                      Originally posted by rene View Post
                      Also repeating false claims all day long do not make them more true. I guess there is a reason Linus Torvalds comments on real world tech and not Phoronix. It is probably time to ignore this News plumbing website, ...
                      No Linus Torvalds is smarter than you on these topics. Big thing he does not comment on massive multi processing system problems.


                      reading from one process > >> per core (96 total) was 491x slower.

                      There are benchmarks back in 2016 showing exactly what I described where the atomics operations with sysfs/procfs on large core and thread count systems could start causing massive slow downs.

                      This is the problem that readfile is attempting to address. False claims my ass. The Amdahl's law problem that comes from atomic operations can be demonstrated with benchmarks we are not talking little bits of slow down here pushed the right way a brand new 4Ghz 128 core Epyc system can make a XT computer appear fast.

                      How is your vectored syscall idea going to deal with the fact you have to reduce atomic operations. That right its not going to.

                      Comment

                      Working...
                      X