Announcement

Collapse
No announcement yet.

Fedora 33 Looking To Use Swap On zRAM By Default With systemd's zram-generator

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

  • Fedora 33 Looking To Use Swap On zRAM By Default With systemd's zram-generator

    Phoronix: Fedora 33 Looking To Use Swap On zRAM By Default With systemd's zram-generator

    Some Fedora spins have already made use of swap on zRAM for serving as a compressed RAM drive while with Fedora Workstation 33 they are looking to make use of zRAM by default...

    http://www.phoronix.com/scan.php?pag...-zRAM-Proposal

  • #2
    I hope they do since it's more helpful than harmful. Plus I like it when distributions do what I do by default.

    Michael I think you mean one here.

    Once could argue it's long overdue

    Comment


    • #3
      I guess I don't understand - if you have enough memory to use a RAM-drive for swap, couldn't you just disable swap and keep everything in memory anyways?

      Comment


      • #4
        Originally posted by AmericanLocomotive View Post
        I guess I don't understand - if you have enough memory to use a RAM-drive for swap, couldn't you just disable swap and keep everything in memory anyways?
        You could, though the point of zram is "disk" compression - fitting more pages into the space than simply running it raw. It's also intended for low-spec situations where you want to avoid writing too many times to the onboard flash storage (benefiting phones, SD/USB installations, and netbooks for example.)

        Comment


        • #5
          Originally posted by AmericanLocomotive View Post
          I guess I don't understand - if you have enough memory to use a RAM-drive for swap, couldn't you just disable swap and keep everything in memory anyways?
          You could, but then it won't be compressed.

          Comment


          • #6
            i wonder when will systemd-kernel will pop up?

            Comment


            • #7
              Originally posted by AmericanLocomotive View Post
              I guess I don't understand - if you have enough memory to use a RAM-drive for swap, couldn't you just disable swap and keep everything in memory anyways?
              While usage strategies vary, one of them is to put a small amount of swap in zram just so the system has some swap space. That's common for legacy things that require or expect an actual swap to exist and why I use it. I would rather have my emergency in case shit happens swap there versus on a disk.
              Last edited by skeevy420; 06-06-2020, 10:32 AM.

              Comment


              • #8
                Is Fedora going to avoid swap fallback on disk completely? How would they go about supporting hibernation?

                Originally posted by AmericanLocomotive View Post
                I guess I don't understand - if you have enough memory to use a RAM-drive for swap, couldn't you just disable swap and keep everything in memory anyways?
                The point of zram is for the compression, which can average around 2-3x IIRC, though with zstd I think in some cases much higher. ChromeOS and Android have been making use of zram for quite a while now, despite them traditionally not having large amounts of RAM.

                You can have other swap devices available, like a larger one on disk, and use priorities. However from what I understand, if zram has higher priority and is used first for performance, once that is filled, the disk is used, but the zram one isn't emptied/transferred, like you'd get with RAM and swap for cold/stale data, I suppose at that point it's not all that different from just not using zram in the first place, however zram supports a backing storage for idle/incompressible pages, such that you can probably avoid the problem if configured properly to support that feature.
                Last edited by polarathene; 06-06-2020, 11:26 AM.

                Comment


                • #9
                  Originally posted by polarathene View Post
                  Is Fedora going to avoid swap fallback on disk completely? How would they go about supporting hibernation?



                  The point of zram is for the compression, which can average around 2-3x IIRC, though with zstd I think in some cases much higher. ChromeOS and Android have been making use of zram for quite a while now, despite them traditionally not having large amounts of RAM.

                  You can have other swap devices available, like a larger one on disk, and use priorities. However from what I understand, if zram has higher priority and is used first for performance, once that is filled, the disk is used, but the zram one isn't emptied/transferred, like you'd get with RAM and swap for cold/stale data, I suppose at that point it's not all that different from just not using zram in the first place, however zram supports a backing storage for idle/incompressible pages, such that you can probably avoid the problem if configured properly to support that feature.
                  I've been using zram with the z3fold zpool algorithm and the lz4 compression algorithm with a disk partition backing it for a couple of years now. As I type this, z3fold yields a compression ratio of 2.826. Sadly, it decompresses the pages it swaps out to its backing storage it seems. But I guess that is a price worth paying.

                  As an aside, I've also been using an lz4 compressed kernel during that time (on a whim I checked the difference between an lz4 compressed kernel and an xz compressed kernel on an old q9400 back during the 4.19.x timeframe and was impressed at how much faster lz4 felt compared to xz during boot so I just switched and never looked back).

                  Nice to see that distributions are catching on to the fact that lz4 can help improve the boot (Ubuntu) and swap (Fedora) experience respectively.
                  Last edited by ermo; 06-06-2020, 01:34 PM.

                  Comment


                  • #10
                    And why not zswap instead !?
                    I think is far superior!

                    Comment

                    Working...
                    X