Announcement

Collapse
No announcement yet.

Fedora Workstation 33 Aiming To Have SWAP-On-ZRAM By Default

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

  • Fedora Workstation 33 Aiming To Have SWAP-On-ZRAM By Default

    Phoronix: Fedora Workstation 33 Aiming To Have SWAP-On-ZRAM By Default

    Fedora IoT already uses swap-on-ZRAM by default given IoT devices are often running with limited amounts of RAM, but for Fedora Workstation 33 the developers are looking at enabling SWAP-on-ZRAM by default for all new installations...

    http://www.phoronix.com/scan.php?pag...s-SWAP-On-ZRAM

  • #2
    Will this keep the swap file?

    I hibernate my computer a lot and Fedora performs wake-up from hibernation perfectly the vast majority of the time, would be a shame if that was no longer a thing.

    Comment


    • #3
      skeevy420 already does this by default

      Britoid I'm not sure, but it isn't like you can't just add a new swap file if it swaps the swap to the new swap spot...and say that 3 times fast

      Comment


      • #4
        Originally posted by skeevy420 View Post
        skeevy420 already does this by default

        Britoid I'm not sure, but it isn't like you can't just add a new swap file if it swaps the swap to the new swap spot...and say that 3 times fast
        Should of said swap partition, swap files are much less reliable than swap partitions for restoring.

        Comment


        • #5
          Originally posted by Britoid View Post

          Should of said swap partition, swap files are much less reliable than swap partitions for restoring.
          I wouldn't know. I have 48gb of ram on my system. It just takes too long to hibernate and restore when you have that much ram...and I don't really want a 50GB swap partition.

          I limit my swap to 8GB in zram...and I only have that swap for "just in case legacy shit happens".

          Comment


          • #6
            Originally posted by skeevy420 View Post

            I wouldn't know. I have 48gb of ram on my system. It just takes too long to hibernate and restore when you have that much ram...and I don't really want a 50GB swap partition.

            I limit my swap to 8GB in zram...and I only have that swap for "just in case legacy shit happens".
            You can usually hibernate successfully with less swap than available RAM, the kernel will attempt to compress and fit the used memory into the available swap space.

            On a laptop you're only looking at 8-16GB of RAM anyway.

            Comment


            • #7
              Originally posted by Britoid View Post

              You can usually hibernate successfully with less swap than available RAM, the kernel will attempt to compress and fit the used memory into the available swap space.

              On a laptop you're only looking at 8-16GB of RAM anyway.
              The problem with the first option is, at least the last time I tried anyways, a full reboot cycle was faster than just going into hibernation, let alone restoring it.

              Pretty soon laptops will be 16-32GB and some lines already are. Luckily for them there are SSDs and fastboot and dudes at Red Hat constantly trying to shave 1ms here and there from the startup process.

              I wonder how long it'll be until laptops come with two drives -- primary drive and hibernate drive.

              Comment


              • #8
                Originally posted by skeevy420 View Post

                I wonder how long it'll be until laptops come with two drives -- primary drive and hibernate drive.
                That's how Intel Rapid Start worked.

                It's gone now, it got replaced because Windows is very good at hibernation and session restore.

                Probably need to move to a system where a hibernate file can be created on-demand.

                Comment


                • #9
                  Originally posted by Britoid View Post

                  That's how Intel Rapid Start worked.

                  It's gone now, it got replaced because Windows is very good at hibernation and session restore.

                  Probably need to move to a system where a hibernate file can be created on-demand.
                  That's not a bad idea and I'm surprised we're not doing it like that now.

                  Comment


                  • #10
                    Originally posted by skeevy420 View Post
                    The problem with the first option is, at least the last time I tried anyways, a full reboot cycle was faster than just going into hibernation, let alone restoring it.
                    Hibernation by default aims for 40% compression of RAM(2/5th the size). You can reduce that target to 100%(5/5) if you don't care for compression and it'll just write the contents to disk. On a SATA SSD, if it has to write 48GB yeah that would be slow, around 1 min 30? But afaik only actual allocated memory is written to disk for hibernation?

                    Originally posted by Britoid View Post
                    Windows is very good at hibernation and session restore.
                    Windows hibernation exists? I thought it does hybrid sleep now, so it suspends to RAM for resume, but can write to disk for hibernation. Regular suspend to RAM(S3) also gets phased out for Suspend to Low Power Idle (S0ix), which if implemented well lets s2idle go into power efficient states but still allow for some other hardware to be a bit awake, like wifi, they call it Modern Standby?

                    When you shutdown/restart, it logs out of the user session to free up RAM, then hibernates from there to reduce load times apparently, provided Fast Startup is enabled.

                    Originally posted by Britoid View Post
                    Probably need to move to a system where a hibernate file can be created on-demand.
                    You can assign the hibernate swap target as a different one than usual swap storage afaik(see Arch Wiki). Or use hybrid-sleep, optionally with a delay to wake from suspend and then hibernate.

                    Comment

                    Working...
                    X