User: Password:
Subscribe / Log in / New account



Posted Feb 19, 2009 12:20 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Why? by khim
Parent article: From wakelocks to a real solution

XO is a different case - the runtime idle states on x86 are signifiantly higher power draw than on modern SoCs. OMAP and the MSM chips used in the G1 are effectively equivalent in runtime idle and suspended states. The concept of a "suspended mode" is dying out in many markets, so optimising for it is foolish. Nokia have succeeded in demonstrating that it's unnecessary when you have the appropriate hardware support.

(Log in to post comments)


Posted Feb 24, 2009 18:30 UTC (Tue) by tbird20d (subscriber, #1901) [Link]

Nokia (and TI really) have demonstrated that with near-infinite hardware knobs and Herculean software effort, you can pull this off. But the methods are not generalizable to other platforms, scalable, or IMHO sustainable in the long-term.


Posted Feb 24, 2009 18:49 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

For functional deep runtime power management, you need three things:

1) The hardware to support it. That's increasingly the case - multiple vendors provide this kind of functionality.
2) The OS to support high quality driver power management. That requires paying attention to application requirements and aggressively reducing the power consumption of hardware when those requirements are relaxed.
3) The userspace applications not to use resources unnecessarily, or some way to actively prevent them from being given them.

(1) is entirely out of our control. For hardware that supports low-latency full-system suspend/resume and doesn't support ultra low-power runtime idle modes, we don't have any option - the only solution is some sort of automatic system suspend.

However, I'm going to argue that that's not especially interesting. Hardware that falls into this category is a decreasing proportion of the market. ARM is mostly heading towards supporting sufficiently deep runtime idle. x86 doesn't have sufficiently low-latency suspend/resume for automatic suspend to be practical. Optimising for this scenario is optimising for a dying market segment.

(2) and (3) are interesting because they benefit the entire Linux market, not merely a segment of the embedded market. Enhancing our driver framework allows us to save power in everything from the phone to the server. Ensuring that our software stack doesn't engage in pathological behaviour provides the same benefits.

Concentrating on wakelocks simply ignores the reality that they provide no benefit in most usecases. In the Android case, they're a bandaid to hide inadequacies in other software layers.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds