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

[Nigel Cunningham <ncunningham@crca.org.au>]

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