Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

Nigel Cunningham
2006-07-11T22:01:29Z

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

Hi.

On Wednesday 12 July 2006 07:54, Rafael J. Wysocki wrote:
> Hi,
>
> 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%.

Ah ok. Are you sure you're getting that sort of throughput with LZF though -
if you're not, you might be underestimating the advantage.

Regards,

Nigel
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]