[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 15:55 -0700, Linus Torvalds wrote:
    > On Thu, 26 Apr 2007, Nigel Cunningham wrote:
    > > >
    > > > And name *one* thing that have in common.
    > >
    > > Set/reset the scsi transaction id thingy? Hibernation didn't work with
    > > SCSI for a long time precisely because that support was missing.
    > And by "hibernation", you mean what? You mean "snapshot + shutdown",
    > right?
    > Think about it for five seconds, and then ask yourself: at which point in
    > the "snapshot + shutdown" sequence would you actually tell a disk to shut
    > down?
    > If you said "snapshot", then you'd be *wrong*.

    No, I didn't. I agree with you that they should be separate and
    distinct. I'm just pointing out that you're overstretching your argument
    a little. There are some similiarities in that in both cases we want to
    get the driver into some quiet state and out of it again. The difference
    comes from the fact that the quite states don't have to be the same and
    shouldn't be the same. I won't insult your intelligence by describing
    the differences in more detail.

    > That's my _point_. The snapshot() function should not (and MUST NOT) tell
    > disks to shut down, because unlike suspend(), we're still going to _use_
    > those disks afterwards (why? To write out the snapshot image!).
    > In other words, the act of creating a snapshot has *nothing* to do with
    > suspend.

    Absolutely. It's about getting the data we need to restore it to the
    same state post-hibernation-cycle (or, more correctly)

    > Now, after you've created (and written out) the snapshot, what do you
    > actually end up doing?
    > That's right - you end up _shutting down_ the machine, and yes, as part
    > of the _shutdown_ sequence you may actually end up doing a lot of the
    > things that a suspend would do. But that's long *after* you've actually
    > done the "snapshot" part, and has absolutely nothing to do with it.
    > That's where I started: whole "suspend to disk" thing actually has _more_
    > to do with "shutdown" than with "suspend".

    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. Unlike suspend, we don't
    necessarily want it to enter a low power-usage state as part of that
    state preservation.

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2007-04-26 08:33    [W:0.032 / U:35.212 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site