I don't buy this argument either
Posted Feb 19, 2009 10:40 UTC (Thu) by khim (subscriber, #9252)
If you run some wild application you can make your system slow down so
much that sshing to it and killing offending process is impossible. Somehow
the answer "fix your userspace" was never considered "good enough" and
years were spent developing many systems (quotas, cotainers, VMs) to make
it safe to run any application and still have control over system.
Sure: any application will consume resources. But with phone you need
guarantee that consumed resources (all resources including power) are
limited by some arbitrary value. If it's enough for program - it'll work
great, if not - I can decide if fancy screen-saver worth giving it half of battery resources.
The same story as with preemptive vs cooperative multitasking: cooperative multitasking works great if you have control over all programs
(see Novel Netware 3.x), but if not - it's disaster (see Windows 3.x and/or
MacOS before MacOS X).
Posted Feb 19, 2009 10:50 UTC (Thu) by mjg59 (subscriber, #23239)
Posted Feb 19, 2009 12:10 UTC (Thu) by khim (subscriber, #9252)
Stopping every single userspace process from running is an awfully blunt tool to prevent poorly written apps from spending battery power
Somehow I doubt you can save as much power by using any other approach. XO tried to do this, G1 is doing this - I'm pretty sure it'll be standard approach in some niches for years to come. And why should a single poorly-written application be able to suck your battery dry if system is designed to mostly live in suspended mode?
Kernel already is doing things like that. Only there kernel guarantees small amount of time for "normal" process here it gurantees only small amount of work time for any process. Different systems, different requirements...
Posted Feb 19, 2009 12:20 UTC (Thu) by mjg59 (subscriber, #23239)
Posted Feb 24, 2009 18:30 UTC (Tue) by tbird20d (subscriber, #1901)
Posted Feb 24, 2009 18:49 UTC (Tue) by mjg59 (subscriber, #23239)
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 © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds