Announcement

Collapse
No announcement yet.

Faster Reading From /dev/zero With Linux 5.10

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

  • #11
    Originally posted by torsionbar28 View Post
    I'm getting 6.85GiB/s on DDR3-1600, and 6.14GiB/s on DDR3-1066. Sounds like you must have one of those newfangled DDR4 whizboxes.
    this test does not access memory at all, it should be limited to the innermost caches. 19.3GB/s for my old haswell.

    Comment


    • #12
      Originally posted by Christophe Leroy on lkml
      Was measured on an 8xx powerpc running at 132MHz with:

      dd if=/dev/zero of=/dev/null count=1M

      With the patch, dd displays a throughput of 113.5MB/s
      Without the patch it is 99.9MB/s
      ​​​​​good news for people running workloads where a difference between 100 and 113.5 MB/s for reading /dev/zero matters on really weak hardware, I guess.

      Comment


      • #13
        Originally posted by birdie View Post

        pv -petrab /dev/zero > /dev/null

        gives me 19.0GiB/s - can't complain that is close to the maximum memory throughput for this PC.
        Ahh, but how much CPU use does it require?

        Comment


        • #14
          Originally posted by OneTimeShot View Post
          We need a /dev/uzero that doesn't block when the zeros are exhausted.
          But we also need to do a remark that it's cryptological less save, because /dev/uzero has a smaller pool of entropy to get more random 0's.

          Joking aside, /dev/zero is important in all sorts of ways. Even if it is to just be able to mmap 1TB to write to disk.

          Comment


          • #15
            Originally posted by gregzeng View Post

            So much superior geek speak here, that I cannot understand the OP, nor the comments. Is this DEV ZERO the cause of the standard Linux "feature" of waiting 90 seconds for the "disk" to be located? It happens so frequently that most of us hate Linux. There seems to be a bad CFG fault somewhere that no person dares mention. The only way I know to work around it is to re-install the Linux system, on top of itself, without formatting the partition. Crazy error-causing Linux for any person who dares trying multi-booting.
            /dev/zero is a source for 0. It's handy in all kinds of ways. As a COW for other memory mapped files. Just as a source for 0 bytes. It has never been buggy or slow for the user experience, but it has been slow for the kernel developer experience. This fix probably opened a can of, oh look, that's also slow.
            So no, it's not for you, but nice to know that tiny details are improved.

            Comment


            • #16
              Originally posted by smitty3268 View Post

              Ahh, but how much CPU use does it require?
              100% of a single core (Ryzen 7 3700X) which means it's CPU limited.

              Comment


              • #17
                Originally posted by mlau View Post

                this test does not access memory at all, it should be limited to the innermost caches. 19.3GB/s for my old haswell.
                ~15GB/s * 8 on my Ryzen.
                Looks like you are correct.

                Comment


                • #18
                  Originally posted by birdie View Post
                  100% of a single core (Ryzen 7 3700X) which means it's CPU limited.
                  Nice, my 6.85GiB/s is also on a 65w TDP chip, an Opteron 4376.
                  Last edited by torsionbar28; 07 September 2020, 08:34 PM.

                  Comment


                  • #19
                    Originally posted by gregzeng View Post
                    the standard Linux "feature" of waiting 90 seconds for the "disk" to be located? It happens so frequently that most of us hate Linux. There seems to be a bad CFG fault somewhere that no person dares mention. The only way I know to work around it is to re-install the Linux system, on top of itself, without formatting the partition. Crazy error-causing Linux for any person who dares trying multi-booting.
                    I've been using Linux since 1995, with various distributions on many different computers, and have never experienced or even heard of such a thing. It's very unlikely to have anything to do with /dev/zero.

                    Which Linux distribution are you using? What kind of machine are you running it on? Have you posted about the problem in support forums for the distribution?

                    Comment


                    • #20
                      Originally posted by gregzeng View Post

                      So much superior geek speak here, that I cannot understand the OP, nor the comments. Is this DEV ZERO the cause of the standard Linux "feature" of waiting 90 seconds for the "disk" to be located? It happens so frequently that most of us hate Linux. There seems to be a bad CFG fault somewhere that no person dares mention. The only way I know to work around it is to re-install the Linux system, on top of itself, without formatting the partition. Crazy error-causing Linux for any person who dares trying multi-booting.
                      That's a Systemd "feature," not a kernel feature.
                      You likely have something in your fstab that isn't present during boot, and are using systemd as your init.
                      adding the option 'x-systemd.device-timeout=<number of seconds to wait>' to your drive's fstab entry should fix that, or switch your init system (I did the latter for a number of different reasons). Don't set the number to zero or it'll wait forever.

                      If you have an 'ntfs-3g' partition in your fstab, consider adding 'nobootwait' as well. nobootwait is only valid on certain filesystems, though. On Ubuntu, apparently, more kinds support it than in other distributions.

                      I don't have systemd init on any of my systems at the moment, but this was true when I did.
                      Last edited by wyatt8740; 15 September 2020, 01:19 PM.

                      Comment

                      Working...
                      X