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

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

Hi,

On Wednesday 12 July 2006 01:00, Nigel Cunningham wrote:
> Hi.
> 
> On Wednesday 12 July 2006 08:34, Rafael J. Wysocki wrote:
> > 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:
> > > > > 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.
> 
> Hmm. I would have expected it to be the other way round, since I guess you 
> need to do the reading synchronously - or do you read the image, then 
> decompress it? (I'm reading and decompressing at the same time, using 
> readahead to avoid waiting for pages all the time).

We're doing something like you are, but I think we're using some other option
in LZF, because the resulting image size is 30-40% of the uncompressed one.
That's better for encryption later on, but obviously not for speed.

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