On Fri, May 6, 2022 at 9:08 AM Pavel Machek <pavel@xxxxxx> wrote: > > Hi! Hi Pavel! > > > One annoyance of the "preloading" scheme is that hibernate image memory > > is effectively double-allocated: first by the usermode process pulling > > encrypted contents off of disk and holding it, and second by the kernel > > in its giant allocation in prepare_image(). An interesting future > > optimization would be to allow the kernel to accept and store encrypted > > page data before the user key is available. This would remove the > > double allocation problem, as usermode could push the encrypted pages > > loaded from disk immediately without storing them. The kernel could defer > > decryption of the data until the user key is available, while still > > knowing the correct page locations to store the encrypted data in. > > Um. Dunno. Won't you run out of memory? Hibernation images can be quite big... > As you know, with the way the snapshot mechanism works, a hibernation image can be at most 50% of RAM. If the system was using more than that at hibernation time, it has to free up the excess via swap before hibernating. So during this resume period, there's at least 50% of RAM to play around in and still be able to preload the hibernation image. What I've been doing in practice is to load as much of the hibernate image as possible into memory at the login screen while at the same time ensuring the system maintains a comfortable margin of free memory. I have to coerce the kernel into doing its giant allocation in prepare_image() first since it uses GFP_ATOMIC. This might mean I can only preload some of the image from disk. With the disk I/O being by far the longest pole in the tent, hiding even some of that latency behind the password prompt is still great for perceived resume time. -Evan
