On Thu, 27 May 2010 23:40:29 +0200 (CEST) Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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 Reasonable definition I think. However the current implementation doesn't exactly match it. With the current implementation you risk losing wakeups *independent* of the hardware properties. Even with ideal hardware events can be lost - by which I mean that they will not be seen until some other event effects a wake-up. e.g. the interrupt which signals the event happens immediately before the suspend is requested (or maybe at the same time as), but the process which needs to handle the event doesn't get a chance to see it before the suspend procedure freezes that process, and even if it did it would have no way to abort the suspend. So I submit that the current implementation doesn't match your description of "forced", is therefore buggy, and that if it were fixed, that would be sufficient to meet the immediate needs of android. NeilBrown > > opportunistic: > > suspend driven from the idle context, which guarantees to > not lose wakeups. Provided only when the hardware does > provide the necessary capabilities. > > Thanks, > > tglx > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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
