[lkml]   [2006]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

On Tuesday 11 July 2006 14:45, Nigel Cunningham wrote:
> On Sunday 09 July 2006 04:52, Rafael J. Wysocki wrote:
> > Well, I tried really hard to justify the patch that allowed swsusp to
> > create bigger images and 10% was the greatest speedup I could get out of it
> > and, let me repeat, _with_ compression and async I/O. I tried to simulate
> > different workloads etc., but I couldn't get more than 10% speedup (the
> > biggest image I got was as big as 80% of RAM) - counting the time from
> > issuing the suspend command to getting back _responsive_ system after
> > resume.
> Was that 10% speedup on suspend or resume, or both? With LZF, I see
> approximately double the speed with both reading and writing:

I was not referring to the speedup of writing and/or reading.

The exercise was to measure the time needed to suspend the system and get
it back in a responsive state. I measured the time elapsed between triggering
the suspend and the moment at which I could switch between some applications
in X without any noticeable lag due to faulting in some pages (that is a bit
subjective, I must admit, but I was willing to show that bigger images make
substantial difference).

I tested uswsusp with compression (LZF) and two image sizes: 120 MB and
(IIRC) about 220 MB on a 256 MB box. The result of the measurement for the
120 MB image has always been greater than for the 220 MB image, but the
difference has never been greater than 10%.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-07-11 23:57    [W:0.155 / U:6.564 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site