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

[Rafael J. Wysocki]

On Wednesday 12 July 2006 00:01, Nigel Cunningham wrote:
> On Wednesday 12 July 2006 07:54, Rafael J. Wysocki wrote:
> > 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.

Certainly I don't get that kind of speedup for writing.  For reading I do.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/