On Friday, 3 November 2006 14:57, Stefan Seyfried wrote:
> On Thu, Nov 02, 2006 at 04:08:20PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, 2 November 2006 13:13, Stefan Seyfried wrote:
> > > On Thu, Nov 02, 2006 at 11:29:47AM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, 2 November 2006 11:24, Pavel Machek wrote:
> > > > > Hi!
> > > > >
> > > > > > The appended patch allows the users of suspend to abort the image
> > > > > > saving by
> > > > > > pressing Ctrl+c.
> > > > >
> > > > > It would be nice to abort with escape or something... ctrl+c is going
> > > > > to be "interesting" for users using splashscreen.
> > > >
> > > > OK
> > >
> > > Escape (and f2) switches the splash screen to verbose. I sometimes
> > > probably
> > > would want to do that without aborting suspend.
> > >
> > > I'm not sure if the first escape (that switches bootsplash to verbose) is
> > > even passed on to the terminal, though. Would need to test that...
> >
> > OK
> >
> > Which key do you prefer?
>
> I don't know. Escape sounds pretty logical :-)
> Go ahead, i don't even know if this is an issue (Holger could probably test
> what happens to the escape that sends bootsplash into verbose mode, i'm not
> sure if this one is even propagated to userspace) and if it is, i could still
> either change the define for the SUSE package or
>
> if (bootsplash.is_silent())
> ignore_first_esc;
>
> something ugly like that.
>
> > > > > Otherwise it looks okay.
> > >
> > > Another thing: for me, writing the image actually often consumes much less
> > > time than "freeing some memory" or creating the snapshot does.
> > >
> > > I understand that aborting during snapshot creation might not be possible,
> > > but can we also abort during "freeing memory"?
> >
> > This is happening in the kernel, so no, we can't.
>
> Ok, maybe this is something we should look into later, since i really often
> see machine freeing memory for 30 seconds, snapshotting for another 20 seconds
> and then writing for 10 seconds (or at least it feels like that :-).
The freeing of memory for 30 sec. happens if there are lots of slabs before
the suspend. The memory shrinker is not good at freeing slab caches, to say
the least, but this stuff is quite complicated.
> Pavel never has those machines, but i seem to always have, i also always had
> those that were unusably slow when writing the in-kernel-swsusp image :-)
The current code (as in 2.6.19-rc4) is reasonably fast, although still slower
than the userland with compression (on my boxes).
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
