This is for folks who use hibernation or suspend-then-hibernate with their laptops.

I have an InfinityBook 15 from Tuxedo Computers. The other day, I was starting it up, and wondering “what exactly is it doing when waking up from hibernation?” Now, some of that isn’t just de-hibernating — Linux is booting up, I have a pause at the Grub menu for a few seconds, Tuxedo’s BIOS doesn’t provide much by way of options to speed up boot time. But…at least sometimes, there’s an unexpectedly long time while it’s just sitting there, the Linux kernel has booted, and it’s just saying that it’s resuming from hibernation. I mean, what the Sam Hill is it doing?

This laptop has a bunch of RAM in it – 96GB. Most of that is just used for read caching. So I think…“I wonder if it’s saving and restoring the read cache”?

So just out of curiosity, I hibernate, resume, and then take a look at top’s output, and yeah, the “buff/cache” is pretty full right after waking up from hibernation, when it won’t have had time to read much in. Hmm.

So I drop the read caches:

 # echo 3 > /proc/sys/vm/drop_caches
 # grep ^Cached: /proc/meminfo 
 Cached:          1156352 kB
 #

And then go hibernate:

# systemctl hibernate

Wait until it’s down, hit the power button and time it, and sure enough, now it takes about 26 seconds by my stopwatch to come back up.

Re-fill the read cache:

$ find /home -type f -print0 |xargs -0 cat >/dev/null

# grep ^Cached: /proc/meminfo 
Cached:         92876908 kB
#

Hibernate:

# systemctl hibernate

And now it’s up to ~50 seconds by my stopwatch to come back up. Well, hell. Dropping the read caches alone can halve the total wake-from-hibernation time on this laptop.

So, the impact here is gonna depend on how much memory a laptop has, and the bandwidth of the disk media. But…my guess is that for most people, on solid state storage, a re-warmed read cache is of limited value. They probably benefit from just dropping the read cache before hibernation and then letting use restore the read cache.

So for most users, my guess is that hooking something to drop the read cache into their hibernation process might make sense.

For myself, I don’t really care how long it takes my laptop to hibernate — I use suspend-then-hibernate so that I can close my laptop for brief periods to move it from place-to-place without it hibernating, so the actual hibernation is happening five minutes after I’ve put it in my backpack, when I’m not paying attention to it:

$ grep ^HandleLidSwitch /etc/systemd/logind.conf
HandleLidSwitch=suspend-then-hibernate
HandleLidSwitchExternalPower=suspend-then-hibernate
$ grep ^HibernateDelaySec /etc/systemd/sleep.conf
HibernateDelaySec=300
$

But while I don’t care much about the hibernation time, I do like having it up sooner when I do want to use it.

Even if I did care about re-warming the disk cache on SSD, it’d probably be better to do something like dump the list of pages in the buffer cache from the kernel to a file, then have some daemon running at something like nice -n20 ionice -c3 to re-read those pages into the read cache subsequent to the wake-up, but not blocking the laptop from being used.

  • glitching@lemmy.ml
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    9 days ago

    I’ve managed on a couple of my old laptops to set suspend-then-hibernate so that it restores from hibernation faster than coldboot, but that was with 16 GB RAM; can’t imagine what 6x that does.

    anyhow, try switching to systemd-boot and disable the pause altogether (menu will pop up if you press arrow key), use efibootmgr to set the timeout to 0 and possibly systemd-analyze to check if there’s additional holdups during boot. I also seem to remember shaving additional secs when I switched from swap file on encrypted btrfs to separate, unencrypted swap partition (no decrypt prompt at boot).

      • glitching@lemmy.ml
        link
        fedilink
        English
        arrow-up
        2
        ·
        9 days ago

        not sure what you’re asking me, but to explain: the main file system is still encrypted, only the swap is unencrypted. swap is off during normal operation so when dumping to disk systemd turns off zram and activates swap (and the inverse on restore). so when restoring, it boots superfast, no decrypt prompts, restores from the swap partition, and dumps you right at the lock screen - feels magical, almost mac-like.

        it’s def less secure that way, but for my threat model (lost or stolen device) that’s plenty secure - it’s highly improbable someone will forensic the shit out of my swap to get at my decryption keys, it’s more likely it’ll get sold or parted out.