On Thu, 26 Apr 2007, Nigel Cunningham wrote:
>
> That's where I think you're overstretching the argument. Like suspend
>(to ram), we're concerned at the snapshot point with getting the hardware
>in the same state at a later stage.
Really, no.
"suspend to ram" doesn't _have_ a "snapshot point".
I've tried to explain this multiple times, I don't know why it's not
apparently sinking in. This is much more fundamental than the fact that
you don't want to stop disks for snapshotting, although it really boils
down to all the same issues: the operations are simply not at all the
same!
I agree 100% that "snapshot to disk" is a "snapshot event". You have to
create a single point in time when everything is stable. And I'd much
rather call it "snapshot to disk" than "suspend to disk" to make it clear
that it's something _totally_ different from "suspend".
Because the thing is, "suspend to ram" is *not* a snapshot event. At no
point do you actually need to "snapshot" the system at all. You can just
gradually shut more and more things down, and equally gradually bring them
back up. There simply is *never* any "snapshot" time from a device
standpoint, because you can just shut down devices in the right order AND
YOU ARE DONE.
Really.
[ Obviously s2ram does have one "magic moment", namely the time when the
CPU does the magic read from the northbridge that actually turns off
power for the CPU. But that's really a total non-event from a device
standpoint, so while it's undoubtedly a very interesting moment in the
suspend sequence, it's not really relevant in any way for device
drivers in general. Not at all like the "snapshot moment" that requires
the whole system to be totally quiescent in a "snapshot to disk"! ]
And the reason s2ram doesn't have a that "snapshot" moment is exactly that
the RAM contents are just always there, so there's no need to have a
"synchronization event" when ram and devices match. The RAM will *always*
match whatever any particular device has done to it, and the proper way to
handle things is to just do a simple per-device "save-and-suspend" event.
And yes, the _individual_ "save-and-suspend" events obviously needs to be
"atomic", but it's purely about that particular individual device, so
there's never any cross-device issues about that.
For example, if you're a USB hub controller, which is just about the most
complex issue you can have, you obviously want to "save the state" with
the controller in a STOPPED state, but that should just go without saying:
if the controller isn't stopped, you simply *cannot* save the state, since
the state is changing under you.
The difference is, that the USB driver needs to just "stop, save, and
suspend" as one simple operation for s2ram. In contrast, when doing
snapshot to disk, it cannot do that, because while it does want to do the
"stop" part, it needs to do so _separately_ from the "save" part because
you need to stop everything else *too* before you "save" anythng at all.
Linus
-
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/
