Richard A. Smith wrote: > In any case time based suspend is not where we want to go anyway. We > need proper idle detection and some sort of API such that apps which > have a workload that idle detection is difficult can specify that they > need idle-suspend.
I'm repeating myself (I promise I'll stop) but the method for this in Linux is "cpuidle".[1] cpuidle is incredibly poorly advertised, but it's a very good system. It maintains a list of all available CPU states, along with the latency to enter and exit them. Because it operates inside the kernel, mode selection can be made with full knowledge of any upcoming timed wakeup requests from userspace. To handle unpredictable interrupts, cpuidle uses recent history to predict the frequency of future interrupts, and then chooses processor states to meet an associated latency requirement. It seems likely to me that this will avoid any need for a special idleness API. cpuidle is already used by the kernel to select the ACPI state, but it is possible to add more states as well. Therefore, it seems to me that the logical thing to do is to add the "frozen" state to cpuidle's menu. --Ben [1] http://lwn.net/Articles/221791/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
