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@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