[lkml]   [2007]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

    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
    > 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.


    > 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.


    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2007-04-26 09:15    [W:0.027 / U:16.728 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site