On Tue, May 10, 2022 at 5:29 AM Pavel Machek <pavel@xxxxxx> wrote: > > Hi! > > > > > 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 > > There used to be 50% of RAM limit, but it was removed. I'm confused. My mental model of the way this works is that to create the snapshot, we create a copy of every page in use. So if every used page needs another page for its snapshot copy, isn't the theoretical max usage at snapshot time 50%? (Plus or minus some wiggle room for asking the system to shrink a bit, ignoring nosave regions, and leaving a bit of extra working space). Setting aside my potential misunderstanding of the max image size, frontloading as much of the slow I/O work as we can pack into memory is still useful for us in terms of user experience. I was originally planning to include this "deferred user keys" patch in the series, but it started getting a little unpleasant between a) having to keep the auth tags around somewhere since they aren't consumed yet, and b) dealing with highmem and the staging area during replay when the keys finally did come in. So I opted to stop for now and get feedback before going any deeper. -Evan
