On Mon, May 02, 2022 at 11:53:12PM -0400, Chris Murphy wrote:
On Mon, May 2, 2022 at 5:29 PM Jeremy Linton
<jeremy.linton(a)arm.com> wrote:
> And of
> course it also requires disabling swap on zram (which was nonsense on
> the machine anyway, given the disks are faster than it can
> compress/decompress pages).
I don't think it requires disabling swap on zram per se - from what
I've been told the hibernation code knows it can't use it for the
hibernation image, not least of which is it's not big enough for a
contiguous write of the image. The issue might be that so much needs
to be swapped out, to free ~50% RAM, which is used to create the
hibernation image in memory before it's written out. We need a clear
reproducer with logs and get it posted to the Linux memory management
mailing list to see what's going wrong. Since zram is threaded, it's
pretty unlikely drive writes are faster than memory writes with
compression. LZO+RLE is computationally pretty cheap.
In general, hibernation is expected to work if a zram device is present.
Systemd will automatically filter out zram devices from the candidate list.
If it didn't work for you, it's probably somehting like Chris wrote,
not enough swap for the amount of memory used.
> So, on a recent fedora machine, it took me more than 4 hours to
get a
> hibernation file on btrfs plus LUKS encrypted partition working. The
> documentation for that wasn't to be found anywhere on the fedora/RH
> sites and required compiling a tool to do the block offset calculations
> and manually adding the resume_offset options to grub/etc.
systemd has code to calculate the offset. It is used to try to figure
out which of the swap partitions matches swap_offset= configured on
the kernel command line. I guess it'd be helpful if we exposed this
functionality somewhere. Maybe something like
'systemd-analyze suggest-hibernation-config-that-works' ;)
Zbyszek