On Thursday 13 May 2010, Tony Lindgren wrote: > * Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> [100513 14:32]: > > On Thu, 13 May 2010, Tony Lindgren wrote: > > > > > The difference between echo mem > /sys/power/state and suspend blocks > > > is that with suspend blocks the system keeps running. > > > > Irrelevant. Paul wasn't talking about the suspend blockers; he was > > talking about opportunistic suspend. So what's the difference between > > opportunistic suspend and "echo mem >/sys/power/state"? Especially > > when suspend blockers aren't being used? > > Opportunistic suspend is really trying to do runtime PM, see below. NO, IT IS NOT! What it does is to detect situations in which it is desirable to put the _entire_ _system_ to sleep, while runtime PM works on a per-device basis. > > > And that's why > > > it should be handled by runtime power management instead. > > > > Runtime PM is not capable of freezing userspace and shutting down CPUs. > > More or less by definition -- if it could then it wouldn't be "runtime" > > any more, since the processor wouldn't be running. > > Not true. We are already powering off CPUs and rebooting them for > at least omaps in every idle loop using cpuidle. The memory stays on. What about user space, though? Do you freeze it? > > > The suspend blocks seems like a hack to spam filter good and bad > > > apps from timer usage point of view. Applications are categorized > > > as good or bad depending if they grab a susped blocker or not. > > > > You're referring just to the userspace part of the suspend blocker > > API. What about the kernel part? > > IMHO some timer flags should be used in the kernel too. Currently > there's no way of knowing which timers are good or bad from suspend > point of view. How is that answering the Alan's question? 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
