Hi. On Wed, 2007-04-25 at 19:04 -0700, Linus Torvalds wrote: > > 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".
Sorry. I wasn't clear. I wasn't saying that suspend to ram has a snapshot point. I was trying to say it has a point where you're seeking to save information (PCI state / SCSI transaction number or whatever) that you'll need to get the hardware into the same state at a later stage. That (saving information) is the point of similarity. > 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! Miscommunication, I think. Does the above help? > 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. I suppose that's another point of similarity - for snapshotting, the same ordering is probably needed? > [ 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. Yeah. > 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. No interdependencies? I'm not sure. > 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. Agree. Nigel
signature.asc
Description: This is a digitally signed message part