Hi,
On Thursday 27 April 2006 22:55, Pavel Machek wrote:
> > 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 ...
OK, I'm waiting for Nick to respond, then. :-)
Still I'd like to change one more thing in the final patch. Namely,
instead of this:
@@ -153,6 +153,10 @@ static int snapshot_ioctl(struct inode *
case SNAPSHOT_UNFREEZE:
if (!data->frozen)
break;
+ if (data->ready && in_suspend) {
+ error = -EPERM;
+ break;
+ }
down(&pm_sem);
thaw_processes();
enable_nonboot_cpus();
I'd like to do:
case SNAPSHOT_UNFREEZE:
if (!data->frozen)
break;
+ if (data->ready)
+ swsusp_free();
down(&pm_sem);
thaw_processes();
enable_nonboot_cpus();
so unfreeze() won't return the error.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
