On Monday 01 November 2004 14:45, Pavel Machek wrote:
>
> > Anyway, I think what we have defined so far seem to be good enough to
> > start the actual move. The only thing I'd like you to judge is wether we
> > keep the original PM message semantics we discussed, or we move the
> > freeze semantic to a separate flag as discussed in another message so
See below; I think the choice is really between two ways to
snapshot the system during STD:
(a) freeze all ... then later thaw swapdev (and parents), snapshot,
and "set power state" for all
(b) "set power state" for all, then resume swapdev (and parents),
snapshot, then just "set power state" for swapdev (and parents)
Economy of API and testing argues for (b) ... it's also only a
minor delta from STR. The main delta between that and what we
have today is that today we resume ALL (bleech!!) devices, not
just the ones essential to saving the snapshot.
> > that we have some kind of generic way of triggering drivers local PM...
>
> Actually it seems like an implementation detail to me... but I'd vote
> for separate flags. Distinction between "IDLE" and "SUSPEND" seems
> quite unclear to me.
I'm uncomfortable settling on messages before we finish agreeing
on what needs to be done. (And the word "flags" always triggers
my "bad idea" radar, at least until it's sufficiently beaten down.)
For example, I think I realized yesterday that a "freeze" (idle?)
request shares two responsibilities with a "set power state" (suspend)
message. Both need to stop the I/O queues ... and both also need to
save device state (e.g. PCI config space) so a resume() can work.
The only difference being whether device power state is changed.
And I still think I read some folk thinking it's OK to add an
extra power cycle during the STD cycle ... that whole bit about
waking up _only_ the swap device (and ancestors) seems unsettled.
The "freeze" is in one sense maybe just a workaround for not
being able to do that.
> OTOH... there's preparation for shutdown, which does not fit here too
> much, and preparation for apm sleep, which does not fit, either:
Yeah, I noticed APM sleep and ACPI sleep weren't quite the
same. If for no other reason than getting called by "apm -s"
rather than "echo standby > /sys/power/state" ...
> For shutdown, power state is not interesting, and you do not even need
> to freeze, but you'd better spin down the disks, or you loose your
> data.
Well, that's just a case of properly quiescing the system.
It's not so much spinning down, as completely flushing the
I/O queue ... no dirty pages in Linux or disk drive caches.
> For apm suspend... noone knows whats really required. Theoretically,
> neither freeze nor powersaving is needed.
APM standby is like S1, APM suspend is more like S3. It's been
ages since I've done much with APM, but I certainly know that
pci suspend calls get made even for "apm -s" (standby).
Quiescing the system before standby or suspend (or hibernate!)
certainly wouldn't hurt.
- Dave
