[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#343440: Resuming from suspend to RAM with 2.6.14-5 fails significantly more often than with 2.6.14-4



Am Donnerstag, den 02.11.2006, 18:01 +0100 schrieb maximilian attems:
> hello thomas,
> 
> [...]
> > Yeah, frustrating from a user's point of view, but absolutely
> > understandable.
> 
> we try our best so you'll see in Debian 2.6.18 several backported
> swsusp patches.
> http://svn.debian.org/wsvn/kernel/dists/trunk/linux-2.6/debian/changelog?op=file&rev=0&sc=0

Hello maks,

That is very good.  Thanks for the link (retrieving package information
in synaptic doesn't always work), I well remember the day when I read
the notes for 2.6.14-3:
[ maximilian attems ]
  * Reenable CONFIG_SOFTWARE_SUSPEND on i386 and ppc, resume=/dev/<other device>
    must be set by boot loader. (Closes: #267600)

You were the hero of my day :).


> 2.6.19 promises a speedier suspend to disk, let' see.

Do you know whether any work was done after 2.6.17 (my last Debian
kernel) to speed up that "Shrinking memory..." phase.  Because that's
where all the time was spent.  Not that the actual writeout was speedy,
but that shrinking thing was definitely the most annoying part.


> and the suspend2 maintainer finaly starts to feed upstream.

It's not that he didn't try earlier :(.  I followed some of the merge
discussions and I was so frustrated how linux development works that I
really thought about switching to that other OS or buying a Mac.  But I
guess you got assholes everywhere.


> <snipp>
> > > suspend2 adds a gif decoder and is not even included in the bloated
> > > ubuntu kernel, see the debian kernel policy
> > > the only sucess of suspend2 is to unload a bunch of drivers and
> > > reoload them, that's most of the difference for the user.
> > 
> > You obviously never used it and don't know what you are talking about.
> > 
> > FYI, suspend2 does not unload a bunch of drivers.  That's the job of a
> > userspace application called hibernate (there is a Debian package with
> > the same name), which I think originates from the suspend2 community but
> > is not specific to it, i.e. it can be used with other suspend methods,
> > too.
> 
> hibernate keeps track of driver, which haven't implementented an resume
> methode like usblp (only latest).

And a lot more.  Really, I used it all the time :).


> > And the real difference to me as a user is the time it takes to suspend
> > the machine.  It is really seconds with suspend2 (say, 20 seconds)
> > compared to a few _minutes_ with swsusp.  When trying it yourself, be
> > sure to suspend a real-life session (i.e. use a substantial part of your
> > RAM).  And then resume your machine and feel the difference. With swsusp
> > it runs like a pig, because everything needs to be paged back in.  With
> > suspend2, you get your machine back like it was when you suspended it
> > (with the file system caches still as hot as before).
> 
> here on an x40 suspend to ram takes not even 1 second and
> suspend to disc varies of the image size but is around 15-25 seconds.

Suspend to RAM works acceptably fast here, too.  Not a single second
(wow!), but, say, three seconds.  I could live with that if it resumed
reliably.  (Plus, the machine really drains batteries, even when S3ed).

15-25 seconds sounds fine, too.  How much of your RAM is used?  It
really is the "Shrinking memory" phase (see above) that takes the time
here.  I have a feeling that it starts being slow as soon as I use more
than half of my RAM.  Which somehow fits to something I read about
swsusp ages ago (that it needs half of the RAM free but that was long
ago and maybe they finally got rid of that).

And what about resuming?  Not the actual resume itself but the feeling
of the machine.


> i have no idea what your laptop is, but i'd be curious if ubuntu
> linux image suspends quicker?

It is a Sony PCG-GRX616SP.  See 

http://www.se.eecs.uni-kassel.de/~thm/Linux/linux-on-sony-vaio-grx616.html

for details.  I haven't completely done the transition from Sid to Edgy
so I haven't got realistic sessions (Gnome, Eclipse, Firefox,
OpenOffice, Evolution, two dozen gnome-terminals, ..) to play with, yet.
I'll followup as soon as I have tried.

Regards, Thomas.




Reply to: