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

Linus Torvalds
2007-04-25T23:21:08Z

On Wed, 25 Apr 2007, Alan Cox wrote:
>
> Both of them have to ensure you can make a consistent snapshot.

Bzzt. Wrong again. Very much so.

STR does not need to "ensure that you have a consistent snapshot".

Why? Becuase there is no _room_ for inconsistency. There's nothing to be
"inconsistent with", since any changes to memory (by things like DMA or
other setup that happens while the suspend process is going on) is by
_definition_ consistent with the resume image (becasue there is no
separate image).

> Doing that means you've got to be able to define a single "point" at
> which the snapshot is made and is internally self-consistent. That in
> both cases tends to mean you've got to ensure nothing occurs which pees
> on the image while you are making that snapshot (such as outstanding
> O_DIRECT I/O to user pages).

Get off the drugs, Alan. There *is* no snapshot with suspend-to-ram.

Which is the whole point I'm trying to make! A _lot_ of people are
confused about this.

With suspend-to-ram, you don't need to do a damn thing to the chip, except
suspend it and resume it. There are _zero_ consistency issues. There is no
need to freeze anything at any point. You can suspend each device totally
independently of all other devices (taking into account things like bus
topology, of course), and there is no "atomic" snapshot that needs to ever
exist.

That's TOTALLY DIFFERENT from "suspend to disk". In suspend to disk, you
need a completely different kind of mindset, namely you need a single
consistent image, where the image is consistent not only with memory, but
with all the devices.

For example, the whole myth that "freeze" needs to shut off DMA is a total
and utter *myth*. It needs nothing of the sort at all. Rather than shut
off DMA and try to make the hardware be wevy wevy quiet while it's hunting
wabbits, it's a lot easier to just do nothing at all on "freeze", and just
make sure that "thaw" will re-initialze the DMA tables entirely! All
drivers have code to do that anyway, since that's what you need to do at
boot.

Notice? Totally different. Absolutely NOTHING in common. Not on a
practical plane, and not even conceptually. The current (broken!)
implementation has forced a totally idiotic model on things, where instead
of snapshotting doing the sane and simple thing, it ends up doing extra
work that is totally unnecessary, but *becomes* necessary just because it
*also* shares the "resume" path (which should _not_ be the same either!)

Linus