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.
Looks like systemd-sleep logs an entry for it, so you can check via this:
One gets either:
Or:
I believe the default on Debian trixie is to suspend on lid close.
But rule of thumb, if you’re coming back from a hibernation, you’ll see your system going through the regular boot process (BIOS screen, GRUB, kernel boot messages or a logo if you have a splash screen instead) up until after the kernel is up. If you’re coming back from a sleep, it’ll just be a black screen until your stuff is back up.