Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

Nigel Cunningham
2007-04-26T07:02:11Z

[-- Attachment #1: Type: text/plain, Size: 3837 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]