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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Wednesday 21 April 2010, Jiri Slaby wrote:
> 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

Thanks for doing that work!

So clearly from performance POV it is better to compress while saving.

Rafael