2010/5/30 Rafael J. Wysocki <rjw@xxxxxxx>: > On Saturday 29 May 2010, Arve Hjønnevåg wrote: >> 2010/5/29 Rafael J. Wysocki <rjw@xxxxxxx>: >> > On Saturday 29 May 2010, Arve Hjønnevåg wrote: >> >> 2010/5/28 Rafael J. Wysocki <rjw@xxxxxxx>: >> >> > On Friday 28 May 2010, Arve Hjønnevåg wrote: >> >> >> On Fri, May 28, 2010 at 1:44 AM, Florian Mickler <florian@xxxxxxxxxxx> wrote: >> >> >> > On Thu, 27 May 2010 20:05:39 +0200 (CEST) >> >> >> > Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: >> >> > ... >> >> >> > To integrate this with the current way of doing things, i gathered it >> >> >> > needs to be implemented as an idle-state that does the suspend()-call? >> >> >> > >> >> >> >> >> >> I think it is better no not confuse this with idle. Since initiating >> >> >> suspend will cause the system to become not-idle, I don't think is is >> >> >> beneficial to initiate suspend from idle. >> >> > >> >> > It is, if the following two conditions hold simultaneously: >> >> > >> >> > (a) Doing full system suspend is ultimately going to bring you more energy >> >> > savings than the (presumably lowest) idle state you're currently in. >> >> > >> >> > (b) You anticipate that the system will stay idle for a considerably long time >> >> > such that it's worth suspending. >> >> > >> >> >> >> I still don't think this matters. If you are waiting for in interrupt >> >> that cannot wake you up from suspend, then idle is not an indicator >> >> that it is safe to enter suspend. I also don't think you can avoid any >> >> user-space suspend blockers by delaying suspend until the system goes >> >> idle since any page fault could cause it to go idle. Therefore I don't >> >> see a benefit in delaying suspend until idle when the last suspend >> >> blocker is released (it would only mask possible race conditions). >> > >> > I wasn't referring to suspend blockers, but to the idea of initiating full >> > system suspend from idle, which I still think makes sense. If you are >> > waiting for an interrupt that cannot wake you from suspend, then >> > _obviously_ suspend should not be started. However, if you're not waiting for >> > such an interrupt and the (a) and (b) above hold, it makes sense to start >> > suspend from idle. >> > >> >> What about timers? When you suspend timers stop (otherwise it is just >> a deep-idle mode), and this could cause problems. Some drivers rely on >> timers if the hardware does not have a completion interrupt. It is not >> uncommon to see send command x then wait 200ms in a some hardware >> specs. > > QoS should be used in such cases. > I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle? -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
