On Thursday 27 May 2010, Thomas Gleixner wrote: > On Thu, 27 May 2010, Rafael J. Wysocki wrote: > > > On Thursday 27 May 2010, Thomas Gleixner wrote: > > > On Thu, 27 May 2010, Alan Stern wrote: > > > > > > > On Thu, 27 May 2010, Felipe Balbi wrote: > > > > > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote: > > > > > >If people don't mind, here is a greatly simplified summary of the > > > > > >comments and objections I have seen so far on this thread: > > > > > > > > > > > > The in-kernel suspend blocker implementation is okay, even > > > > > > beneficial. > > > > > > > > > > I disagree here. I believe expressing that as QoS is much better. Let > > > > > the kernel decide which power state is better as long as I can say I > > > > > need 100us IRQ latency or 100ms wakeup latency. > > > > > > > > Does this mean you believe "echo mem >/sys/power/state" is bad and > > > > should be removed? Or "echo disk >/sys/power/state"? They pay no > > > > > > mem should be replaced by an idle suspend to ram mechanism > > > > Well, what about when I want the machine to suspend _regardless_ of whether > > or not it's idle at the moment? That actually happens quite often to me. :-) > > Fair enough. Let's agree on a non ambigous terminology then: > > forced: > > suspend which you enforce via user interaction, which > also implies that you risk losing wakeups depending on > the hardware properties OK > opportunistic: > > suspend driven from the idle context, which guarantees to > not lose wakeups. Provided only when the hardware does > provide the necessary capabilities. I can accept that definition, but this is not what "opportunistic" means in the Arve's changelogs. What it means there is that he wants the system to suspend even when it is not technically idle (like in the updatedb example I gave in a previous message). Suspend blockers are supposed to be a mechanism by which the kernel and user space together may determine when to suspend (and it's somewhat orthogonal to idle). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
