Mike - > On Fri, Apr 01, 2005 at 10:26:33AM +0200, Mike Bursell <Mike. > [EMAIL PROTECTED]> wrote: > > I'd be surprised if it were firefox, too, but I don't see any other > > applications exhibiting similar behaviour, which confuses me. Maybe > > there's a process that firefox has dependencies on which has problems - I > > don't know. I'm afraid that I'm not enough of a power user to be able to > > say. > > > > Anyway, it's suspend-to-disk, sorry for not saying so. I've attached a > > copy of my kernel config - you may not need it, but I know that a number > > of suspend options are mentioned. > > I don't know exactly how suspend-to-disk works, but I assume it works by > forcing memory pages to be swapped on disk. I assume that at resume > time, it doesn't necessarily swap back all the pages that were in > memory, but only does so on page misses. Thus, having to swap back a > process like firefox, which is usually taking more than 100MB may take > a long time. > That's only an hypothesis.
That had occurred to me. I'll do some testing, but what seems weird is that this problem seems to occur even when firefox isn't loaded. And firefox is _much_ faster starting up from a cold boot than after a resume. So, unless Linux has noticed that it has a copy of firefox which it can access in a page file and this is horribly slower than loading it to start with, I can't see why this might impact. I might try with some other largeish applications (Oo.org?), and see if I get similar behaviour. -Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
