One can think of suspend-to-RAM as nothing more than a super-duper
selective suspend of all devices (including the CPU!). This
illustrates the relationship between suspend-to-RAM and runtime PM.
However there is one important distinction, the DoS issue that Pavel
raised. With true suspend-to-RAM, autoresume on demand is not enabled
-- only on remote wakeup. With runtime PM, both are enabled.
Elegant though it is, the "freeze I/O" approach suffers from
implementation awkwardness. Ideally individual drivers shouldn't have
to worry about it, but the subsystems certainly will.
Consider as an example the class of char device drivers. The only
subsystem they have in common is VFS. It would then be necessary for
every entry point into VFS to check whether a suspend-to-RAM is in
progress, and if it is, block until the suspend is over. Each one of
those entry points is on a hot path, so adding these checks is the sort
of thing one would like to avoid.
By freezing tasks we can eliminate (most) I/O requests at the source
with a single, relatively small amount of code (i.e., the
refrigerator). Freezing I/O, on the other hand, would involve many
checks dispersed throughout a large number of source files -- checks
that would have to execute even when a suspend wasn't in progress.
Alan Stern
-
