Re: [RFC 09/15] PM / Hibernate: user, implement user_ops writer

Nigel Cunningham
2010-03-31T02:31:01Z

Hi.

On 31/03/10 08:03, Rafael J. Wysocki wrote:
>>> Now, an attractive thing would be to compress data while creating the image
>>> and that may be done in the following way:
>>>
>>> have a buffer ready
>>> repeat:
>>> - copy image pages to the buffer (instead of copying them directly into the
>>> image storage space)
>>> - if buffer is full, compress it and copy the result to the image storage
>>> space, page by page.
>>
>> A few points that might be worth considering:
>>
>> Wouldn't compressing the image while creating it rather than while
>> writing increase the overall time taken to hibernate (since the time
>> taken can't then be combined with the time for writing the image)?
>
> It would, but that's attractive anyway, because the image could be larger than
> 1/2 of memory this way without using the LRU pages as temporary storage
> space (which I admit I'm reluctant to do).
>
>> Wouldn't it also increase the memory requirements?
>
> Not really, or just a little bit (the size of the buffer). I'm talking about
> the image that's created atomically after we've frozen devices.

The buffer would be the size of the compressed image. Assuming you rely
on 50+% compression, you'll still need to ensure that at least 1/3 of
memory is available for the buffer for the compressed data. This would
give maximum image size of only 1/6th of memory more than without
compression - not much of a gain.

It's also ugly because if you find that you don't achieve the expected
compression, you'll need to undo the going atomic, free some more memory
and try again - or just give up (which I hope you won't consider to be a
real option).

Regarding using LRU pages as temporary storage, if it wasn't safe and
reliable, I would have stopped doing it ages ago. The only problem I can
recall having was when KMS was introduced, and that was solved by adding
a very small amount of code to let us find those pages and make sure
they're atomically copied instead. We did have a period where we were
paranoid about the issue - the support for checksumming LRU pages prior
to writing the LRU, then checking the checksums prior to the atomic copy
is still in TuxOnIce and used. Searching through my mail archives, I'm
unable to find anyone with a debugging message that says something other
than "0 pages resaved in atomic copy".

Regards,

Nigel