Re: [RFC][PATCH] swsusp: support creating bigger images

[Pavel Machek]

Hi!
> On Tuesday 25 April 2006 12:31, Rafael J. Wysocki wrote:
> > On Tuesday 25 April 2006 12:04, Pavel Machek wrote:
> > > > > Okay, so it can be done, and patch does not look too bad. It still
> > > > > scares me. Is 800MB image more responsive than 500MB after resume?
> > > > 
> > > > Yes, it is, slightly, but I think 800 meg images are impractical for
> > > > performance reasons (like IMO everything above 500 meg with the current
> > > > hardware).  However this means we can save 80% of RAM with the patch
> > > > and that should be 400 meg instead of 250 on a 500 meg machine, or
> > > > 200 meg instead of 125 on a 250 meg machine.
> > > 
> > > Could we get few people trying it on such small machines to see if it
> > > is really that noticeable?
> > 
> > OK, I'll try to run some tests on a machine with smaller RAM (and slower CPU).
> 
> Done, although it was not so easy to find the box.  This was a PII 350MHz w/
> 256 MB of RAM.
> 
> I invented the following test:
> - ran KDE with 4 desktops,
> - ran Firefox, OpenOffice.org 1.1 (with a simple spreadsheet), and GIMP (with
> 2 pictures) each on its own desktop,
> - ran the memory meter from the KDE's Info Center and two konsoles
> on the remaining desktop - one konsole with a kernel compilation and the
> other with a root session used for suspending the box (the built-in swsusp
> was used),
> so the box's RAM was almost fully occupied with ~30% taken by the page cache.
> 
> Then I suspended the box and measured the time from the start of resume
> (ie. leaving GRUB) to the point at which I had all of the application windows
> fully rendered on their respective desktops (I always switched the desktops
> in the same order, starting from the memory meter's one, through the OOo's
> and Firefox's, finishing on the GIMP's one and I always switched the
> desktop as soon as the window(s) on it were fully rendered).
> 
> I ran it a couple of times on the 2.6.17-rc1-mm2 kernel with and without
> the patch and the results (on the average) are the following:
> 
> (a) 25-28s with the patch
> (b) 30-33s without it

Ook, thanks for testing. I guess it is ready for -mm when Nick is
happy with it ...
							Pavel
-- 
Thanks for all the (sleeping) penguins.
-
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/