Messages in this thread |  | | Date | Sun, 27 Aug 2000 11:13:47 -0700 | From | Linda Walsh <> | Subject | Re: Suggestion for laptop suspension |
| |
Hi Richard!
That's sorta odd behavior -- or it would be on my laptop. I can dual (duel? :-) boot Win98 and Gnu/Linux. The suspend to disk behavior is implemented in my BIOS, not in the OS. I can see evidence of this if I go into the BIOS where it allows me to choose suspend to disk or suspend to memory as an option, where I find no similar option in the OS. Also, since I reformated my partition tables way back to split the boot, the BIOS has complained that I stole the partition it would use to suspend to disk or that I added memory (did both) on every boot -- before the OS is ever loaded. I don't think the BIOS can know how much memory an OS is using, since the OS may be loaded in low or high physical memory -- same with any application. Just because I have alot of free memory doesn't mean it is contiguously allocated in low memory.
What I have seen under the Linux (as in the kernel), is that before suspending, it flushes it's disk buffer cache so all dirty data is flushed to disk -- thus if something should happen (like my battery dies when it is suspended to mem), the disk state of all the partitions will be as clean as possible. It's still possible that there will be some inconsistancies, like a file that is open in a process but has no name on disk -- file and inode that would have been released had I shutdown normally, but any data that the system knows is dirty is flushed.
The easiest way to see this is when I'm running VMware with a 128 meg VMspace (which I usually use to run WIN98 in -- dual booting is a headache, and except for a couple of known problems with VMware crashing apps or the guest OS or chopping up sound, running under VMware is usually fine). If I suspend my VMware session, in 2.x, it suspends to 'disk' by default, which means I can exit VMware pronto. Now all of that 128 Meg is written out to the disk cache. If I immediate hit 'Resume', the reponse for VMware to restart the guest OS is virtually instantaneously -- all of the buffers written out are still in the disk cache -- even though they are dirty. Now if I do a 'sync' in a window after a VM-suspend, it takes over 45 seconds to perform the sync. However, restarting the VM is still instantaneous because all of the data I need to restore is still in the disk buffers -- just marked as 'clean' (**- some might also be on the 'free' list if the kernel supports page reclaiming off of the free list...dunno w/o looking).
Now if I hit suspend after a suspend to disk in VMware, it takes a long time to suspend (15-45 seconds) seconds, but if I do the 'sync' first, the suspend happens in under 5 seconds. When I unsuspend, it takes mere seconds (I suspend to memory), and a restart of VMware is also < 5 seconds. Why? Becaue the the host machine memory has been completely restored, buffers and all, which means all of the data needed to restore the VMware image is still in the 'clean' buffer queue -- which is most or all of image needed to start the Virtual Machine in VMWare.
I your situation -- in suspending to disk. If you have alot of dirty buffers, I'm not certain, but I don't think the flush mechanism necessarily orders them for efficiency on write-out or writes out multiple pages at a time that might be contiguous (forgive me if I'm wrong in that assumption, I'm not as familiar with the disk buffer mechanism as I should be). At minimum (in the ordered case), you still have to flush all your dirty buffers which would be a stream of non-contiguous ordered buffers -- the larger your memory and the longer your system has been up, the longer the flush time) and then your memory image has to be written to disk. In the 'worst' case, the buffers are unsorted and written one at a time with could involve lots of random seeks around the disk -- taking a long time, and then the direct copy performed by the BIOS of your system memory to disk (which should be fairly low in comparison). It also makes sense, if you think about it -- if you suspend shortly after the system has been up, there will be darn few dirty buffers that need to be flushed, so your suspend time is near the lower-bound of the BIOS simply copying the physical memory to disk -- again, that is like a minimal time because The BIOS can do it as efficiently as the hardware allows likely one big write w/no seeks.
The 'restore' time should be near constant in either case unless you have low memory and things have been paged out to disk because of the operation of the kernel / apm suspend programs having cause your running program set to be paged out -- in which case when your programs restart, your active set may have to be paged back in from the swap space. Again, a random order, on-demand process.
Does that sound feasible? I'm sure (I hope) someone will add to or correct what I'm saying if my understanding is less than perfect.
-linda
Richard Stallman wrote:
> On my laptop, suspending to disk is slow. It takes a whole minute, and > another minute to unsuspend--if all of core is in use. But it is much > faster when I do it not too long after the system was booted, when it has > not yet managed to use up most of core. > > This suggests that it could be nice to make the kernel empty its caches, and > mark all that core "unused", when a suspend is about to happen. I don't > know the details of how suspension works, so I am not sure this is possible, > but I think there are hooks for doing something in the kernel before a > suspend.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |