benjamin m. schwartz wrote: > 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.
perhaps this should be obvious, but can it handle S-states as well? because i believe that's the goal -- freeze the display and then go into S3. paul > > --Ben > > [1] http://lwn.net/Articles/221791/ =--------------------- paul fox, [email protected] _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
