Announcement

Collapse
No announcement yet.

LZ4 Support Revised For Faster Restore From Linux Hibernation

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

  • #21
    Originally posted by Old Grouch View Post
    For boring reasons, GRUB can't make use of processor opcodes that enable efficient decryption (crypto acceleration), which makes decrypting Argon2id-encrypted keys take faaaar tooooo looooong.
    If you don't need Grub for something specific I can highly recommend using systemd-boot. Easy, slim, and opening argon id is as fast as it is fully booted.

    Comment


    • #22
      Originally posted by Juke1349 View Post
      The problem as I understand it, is that this form of luks-encryption isn't visible to the kernel, and I also want Secure Boot (it's my commute laptop, so higher risk of loss/theft).
      From what I've read, the kernel is currently hardcoded to disable hibernate under secure boot, since it cannot guarantee that it's running on LUKS. And without LUKS, it would create a false sense of security (a decision I agree with).
      Until the kernel itself can checksum+verify the hiberfile, that will remain as is. So this work makes me very happy!
      No, the kernel does not disable hibernate with secure boot. That's a distribution policy using the kernel lockdown feature, which also does other things like disabling loading of unsigned kernel modules.

      Comment


      • #23
        Originally posted by milkylainen View Post

        Boot time has very little to do with UEFI. Most of loader time is taken in various DDR / SERDES training.
        For DDR5, training can be a real pain. We're talking minutes.
        It's a consequence of higher clocks, lower voltages and lower margins to everything.
        Yes I know the DDR5 training takes more time, but this issue is also with DDR3 and DDR4. Also shouldn't the DDR training be ready when you see the fullhd boot screen? It still takes too long after that. For example:

        $ systemd-analyze
        Startup finished in 19.304s (firmware) + 0.781s (loader) + 2.879s (kernel) + 2.121s (userspace) = 25.086s

        Comment


        • #24
          Originally posted by openminded View Post

          From my limited experience, you can reduce uefi post time with disabling network boot support/options. For instance, my laptop spends 5 seconds less on post if I (simply) do not plug ethernet cable (as there's no way to access network boot control options in my BIOS).
          Agree with you anyway.
          I've disabled support for: network boot, csm, sata, serial, parallel, igpu, onboard audio (use hdmi), fullscreen logo. Set the boot delay to 0 seconds. Only try to boot from nvme. I even disabled USB key/mouse support which makes it impossible to access the uefi setup. No help. Micro ATX doesn't have that many onboard devices, either. There's: CPU, 2 x DDR4, GPU, NVMe drive, CPU fan, CMOS battery. That's it. Onboard ethernet is only used by Linux.
          Last edited by caligula; 07 December 2023, 11:16 AM.

          Comment


          • #25
            Originally posted by caligula View Post
            Also shouldn't the DDR training be ready when you see the fullhd boot screen?
            As soon as you see something on your screen, the DDR training is completed. Also training should only happen if you change RAM related Settings in your BIOS or after a CMOS reset (low battery?).

            But I can easily say it's not the training because many boards take much too long while already displaying something. And as said Notebooks are typically < 3s POST how would that be explained? Also some OEM-PCs have fast POST, so it's definitively laziness.

            Comment


            • #26
              Originally posted by Anux View Post
              As soon as you see something on your screen, the DDR training is completed. Also training should only happen if you change RAM related Settings in your BIOS or after a CMOS reset (low battery?).

              But I can easily say it's not the training because many boards take much too long while already displaying something. And as said Notebooks are typically < 3s POST how would that be explained? Also some OEM-PCs have fast POST, so it's definitively laziness.
              Yes I think the machines have become even slower during the last few years. I have few early 2010s Intel based ATX boards from ASUS. They're much faster than the Ryzen boards. It's really surprising because I've swithed from ATX to mATX and in some cases from mATX to ITX. So the boards have less stuff built in. Also the clock speeds are significantly faster. Up to 4,9 GHz vs some older 2 Ghz systems. You would probably assume that a smaller system with less devices and 2,5x faster CPU booted faster.. but no.

              Comment


              • #27
                That's sadly a trend in computing, just start an old DOS machine with a word processor of it's time, it boots faster and the program works more fluid. Whatever new processing power we get is eaten up by bloated and bad engineered software.

                Also Windows might be the reason why board manufacturers don't care, Win mostly uses standby instead of real boot and boards have some sort of fast boot feature to skip everything for this standby hack.

                Comment

                Working...
                X