On 03/31/2010 10:29 PM, Rafael J. Wysocki wrote:
> On Wednesday 31 March 2010, Jiri Slaby wrote:
>> On 03/30/2010 10:50 PM, Rafael J. Wysocki wrote:
>>> So, I definitely would like to see numbers.
>>
>> With the patch attached, I get similar results for
>> uncompressed image -> user.c -> s2disk (compress+threads)
>> compressed image -> user.c -> s2disk (none of compress+threads)
>>
>> BUT note that there are differences in pages _copied_ in the "user.c ->
>> s2disk" phase. Compression was about 40 %. So in the former case 100000
>> pages went through and in the latter one only ~ 38000. So presumably
>> there will be savings if the pages are compressed in the kernel in the
>> save-image phase instead of in userspace.
>>
>> I'll test (after I hack that up) also the case of image compression when
>> saving the image and let you know.
>>
>> It was tested on a machine with openSUSE factory with init 5 with KDE 4.
>> The memory consumption was ~ 400M (100000 pages) after boot every time.
>> Hibernation lasted 12-13s in both cases.
> 
> So that's pretty much the same and I don't think feeding compressed images to
> s2disk is not worth the effort.  Let's assume s2disk will always receive a raw
> image (that will make it backwards compatible too).

Hi.

Yes, I did it solely for comparison purposes.

Now, with the patch attached (depending on either COMPRESS_IMAGE or
COMPRESS_IMAGE1 defined) I tried to compare compression while doing
atomic copy with compression done when image storage takes place. The
latter outperformed the former a bit. I did 8 measurements with the
setup same as above. The average for them is 9684.32 and 10855.07 stored
raw (uncompressed) pages per second. That is 4.5M/s more.

There is a sheet with the numbers at:
http://spreadsheets.google.com/ccc?key=0AvVn7xYA1DnodHFFYzg3Y2tpMUl5NFlURXRtR0xQdmc&hl=en

regards,
-- 
js