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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:19 EST