On Tue, Feb 11, 2020 at 11:50 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > Original thread: > https://lore.kernel.org/linux-mm/CAA25o9RSWPX8L3s=r6A+4oSdQyvGfWZ1bhKfGvSo5nN-X58HQA@xxxxxxxxxxxxxx/ > > This whole thread is a revelation. I have no doubt most users have no > idea that hibernation image creation is expected to fail if more than > 50% RAM is used. Please bear with me while I ask some possibly > rudimentary questions to ensure I understand this in simple terms. To be clear, I am not completely sure of this. Other developers are not in agreement with this (as you can see from the thread). However, I can easily and consistently reproduce the memory allocation failure when anon is >50% of total. According to others, the image allocation should reclaim pages by forcing anon pages to swap. I don't understand if/how the swap partition accommodates both swapped pages and the hibernation image, but in any case, in my experiments, I allocate a swap disk the same size of RAM, which should be sufficient (again, according to the threads). > Example system: 32G RAM, all of it used, plus 2G of page outs (into > the swap device). > > + 2G already paged out to swap > + 16GB needs to be paged out to swap, to free up enough memory to > create the hibernation image > + 8-16GB for the (compressed) hibernation image to be written to a > *contiguous* range within swap device > > This suggests a 26G-34G swap device, correct? (I realize that this > swap device could, in another example, contain more than 2G of page > outs already, and that would only increase this requirement.) > > Is there now (or planned) an automatic kernel facility that will do > the eviction automatically, to free up enough memory, so that the > hibernation image can always be successfully created in-memory? If > not, does this suggest some facility needs to be created, maybe in > systemd, coordinating with the desktop environment? I don't need to > understand the details but I do want to understand if this exists, > will exist, and where it will exist. I have a workaround, but it needs memcgroups. You can echo $limit > .../$cgroup/memory.mem.limit_in_bytes and if your current usage is greater than $limit, and you have swap, the operation will block until enough pages have been swapped out to satisfy the limit. Even this isn't guaranteed to work, even with enough free swap. The limit adjustment invokes mem_cgroup_resize_limit() which contains a loop with multiple retries of a call to do_try_to_free_pages(). The number of retries looks like a heuristic, and I've seen the resizing fail. > One idea floated on Fedora devel@ a few months ago by a systemd > developer, is to activate a swap device at hibernation time. That way > the system is constrained to a smaller swap device, e.g. swap on > /dev/zram during normal use, but can still hibernate by activating a > suitably sized swap device on-demand. Do you anticipate any problems > with this idea? Could it be subject to race conditions? > > Is there any difference in hibernation reliability between swap > partitions, versus swapfiles? I note there isn't a standard interface > for all file systems, notably Btrfs has a unique requirement [1] > > Are there any prospects for signed hibernation images, in order to > support hibernation when UEFI Secure Boot is enabled? > > What about the signing of swap? If there's a trust concern with the > hibernation image, and I agree that there is in the context of UEFI > SB, then it seems there's likewise a concern about active pages in > swap. Yes? No? > > > [1] > https://lore.kernel.org/linux-btrfs/CAJCQCtSLYY-AY8b1WZ1D4neTrwMsm_A61-G-8e6-H3Dmfue_vQ@xxxxxxxxxxxxxx/ > > Thanks! > > -- > Chris Murphy
