On Tue, 29 May 2007, David Brownell wrote: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 -
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 014/196] kobject: remove incorrect comment in kobject_rename |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Stephen Rothwell | Re: Announce: Linux-next (Or Andrew's dream :-)) |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Radu Rendec | htb parallelism on multi-core platforms |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
