On Feb 12, 2006, at 19:51, Phillip Susi wrote:
Alan Stern wrote:
Both of you are missing an important difference between Suspend-to-
RAM and Suspend-to-Disk. Suspend-to-RAM is a true suspend
operation, in that the hardware's state is maintained _in the
hardware_. External buses like USB will retain suspend power, for
instance (assuming the motherboard supports it; some don't).
Suspend-to-Disk, by contrast, is _not_ a true suspend. It can
more accurately be described as checkpoint-and-turn-off. Hardware
state is not maintained. (Some systems may support a special ACPI
state that does maintain suspend power to external buses during
shutdown, I forget what it's called. And I down't know whether
swsusp uses this state.)
I would disagree. The only difference between the two is WHERE the
state is maintained - ram vs. disk. I won't really argue it
though, because it's just semantics -- call it whatever you want.
From the simple perspective, yes, that's the only difference. On
the other hand, from an efficiency standpoint, they are _completely_
different, to a degree that the OS needs to treat them as such or
performance will suck. Software suspend (to disk, network, file,
etc) _requires_ a copy; it's completely mandatory because RAM is
guaranteed to go away. It freezes everything, checkpoints the kernel
with a lot of really complex and oft-buggy code, unfreezes things,
stores data, and shuts off. Hardware suspend (to RAM only)
implicitly needs no copy. The CPU and memory architecture itself
supports the low-power state, so you don't have to do much of
anything special about kernel or userspace threads, you just have to
suspend the device tree once (already exists for per-device power
management) and then tell the firmware to finish up. The former is O
(memory), the latter is O(1).
For a significant majority of people, hardware suspend is
significantly better. I never understood why people need graphical
splash screens during suspend/resume... until I tried software-
suspend. With hardware-suspend, I close it, 2 seconds later the
little white light on the front comes on and it's sleeping, I open
it, 2 seconds later it's connected to wireless again and ready to
use. With software-suspend, it just _doesn't_ work that fast because
of the inherent way it does things; hard disks on laptops are _slow_.
So for example, let's say you have a filesystem mounted on a USB
flash or disk drive. With Suspend-to-RAM, there's a very good
chance that the connection and filesystem will still be intact
when you resume. With Suspend-to-Disk, the USB connection will
terminate when the computer shuts down. When you resume, the
device will be gone and your filesystem will be screwed.
This is not true. The USB bus is shut down either way, and
provided that you have not unplugged the disk, nothing will be
screwed when you resume from disk or ram.
It depends on the hardware. For the disk case, yes, this is true.
On the other hand, for hardware-suspend a number of devices like
keyboards and mice may still be in a low-power suspend mode, allowing
you to wake the computer by pushing keys or mouse buttons.
Cheers,
Kyle Moffett
--
There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
-- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
