On Mon, Aug 12, 2019 at 10:20 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > On Mo, 12.08.19 09:40, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > > > Right now the only lever to avoid swap, is to not create a swap > > partition at installation time. Or create a smaller one instead of 1:1 > > ratio with RAM. Or use a 1/4 RAM sized swap on ZRAM. A consequence of > > each of these alternatives, is hibernation can't be used. Fedora > > already explicitly does not support hibernation, but strictly that > > means we don't block release on hibernation related bugs. Fedora does > > still create a swap that meets the minimum size for hibernation, and > > also inserts the required 'resume' kernel parameter to locate the > > hibernation image at the next boot. So we kinda sorta do support it. > > We could add a mode to systemd's hibernation support to only "swapon" > a swap partition immediately before hibernating, and "swapoff" it > right after coming back. This has been proposed before, but noone so > far did the work on it. But quite frankly this feels just like taping > over the fact that the Linux kernel is rubbish when it comes to > swapping... I'm skeptical as well. But to further explore this: 1. Does the kernel know better than to write a hibernation image (all or part) to a /dev/zram device? e.g. a system with: 8GiB RAM, 8GiB swap on ZRAM, 8GiB swap partition. We can use swap priority to use the ZRAM device first, and conventional swap partition second. If the user, today, were to hibernate, what happens? 2. Are you suggesting it would be possible to build support for multiple swaps and have them dynamically enabled/disabled? e.g. the same system as above, but the 8GiB swap on disk is actually made across two partitions. i.e. a 2GiB partition and 6GiB partition. Normal operation would call for swapon for /dev/zram *and* the small on-disk swap. Only for hibernation would swapon happen for the larger on-disk swap partition (the 2GiB one always stays on). That's... interesting. It sounds potentially complicated. I can't estimate if it could be fragile. Let's consider something else: Hibernation is subject to kernel lockdown policy on UEFI Secure Boot enabled computers. What percentage of Fedora users these days are likely subject to this lockdown? Are we able to effectively support hibernation? On the one hand, Fedora does not block on hibernation bugs (kernel or firmware), thus not supported. But tacitly hibernation is supported because a bunch of users pushed an effort with Anaconda folks to make sure the swap device is set with "resume=" boot parameter with out of the box installations. Another complicating issue: the Workstation working group has an issue to explore better protecting user data by encrypting /home by default. Of course, user data absolutely can and does leak into swap. Therefore I think we're obligated to consider encrypting swap too. And if swap is encrypted, how does resume from hibernation work? I guess kernel+initramfs load, and plymouth asks for passphrase which unlocks encrypted swap, and the kernel knows to resume from that device-mapper device? I'm really skeptical of pissing off users who want hibernation to work. But I'm also very skeptical of compromising other priorities, and diverting resources, just for hibernation. If you wait long enough between replies, I will find another log to throw on this fire, somewhere. :-D -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
