User: Password:
Subscribe / Log in / New account

From wakelocks to a real solution

From wakelocks to a real solution

Posted Feb 19, 2009 7:36 UTC (Thu) by aleXXX (subscriber, #2742)
Parent article: From wakelocks to a real solution

> This is an argument which does not fly particularly well with a lot of
> kernel developers, who respond that, rather than coding the kernel to
> protect against poor applications, one should simply fix those
> applications

Hmm, I don't agree with that. Isn't it after all similar to memory
protection ? If we would trust all userspace applications to be bugfree
and not access memory which is not theirs, there would be no need for
protected memory.
In the same way this protects the system against programs behaving badly
memory-wise, some protection against applications behaving badly
power-consumtion-wise seems like a good thing to me.


(Log in to post comments)

From wakelocks to a real solution

Posted Feb 19, 2009 9:23 UTC (Thu) by dgm (subscriber, #49227) [Link]

Exactly. If you think that the applications are responsible of beeing well-behaver, you'd better use or MS-DOS.

From wakelocks to a real solution

Posted Feb 19, 2009 9:32 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Well, partly because it's impossible to absolutely protect against those applications - they'll still increase your power consumption when you're using your machine.

I don't buy this argument either

Posted Feb 19, 2009 10:40 UTC (Thu) by khim (subscriber, #9252) [Link]

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).

I don't buy this argument either

Posted Feb 19, 2009 10:50 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Stopping every single userspace process from running is an awfully blunt tool to prevent poorly written apps from spending battery power, especially when there are more flexible approaches that allow userspace defined policy.


Posted Feb 19, 2009 12:10 UTC (Thu) by khim (subscriber, #9252) [Link]

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) [Link]

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.


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.

From wakelocks to a real solution

Posted Feb 27, 2009 7:51 UTC (Fri) by efexis (guest, #26355) [Link]

There's actually lot to be said for that. Protected memory mechanisms back on the early 286 CPU's were documented as debugging tools, as they would trap illegal memory accesses, point to where they're occuring, so the software could then be fixed. Assuming all-correct, trusted, and playing-nicely-together software, being able to remove protected and virtual memory mechanisms could actually make a lot of things run a lot lot faster, although of course with downsides too, such as losing automatic copy-on-write memory pages that makes other things run much quicker (like fork()ing). I seem to recall that much stuff that's been launched into space will often do away with memory protection mechanisms as it makes the silicon much simpler.

If we had the man hours to put into the software that would be great, but, it's cheaper to protect against human error (and malace) instead by using software and circuitry. This is often resisted as many feel the desire to Do It Right, but then you get things like probes on Mars deadlocking, and kernel guys going "let's just implement priority inheritance to get it working". I seem to recall Linus being resisant to priority inheritance in the Linux kernel, but eventually an implementation did get in ( Whilst this may not be Doing It Right, it is definitely Doing the Right Thing.


From wakelocks to a real solution

Posted Apr 29, 2010 3:52 UTC (Thu) by cventers (guest, #31465) [Link]

Memory protection is just as necessary for security on a multi-user operating system as it is for crash protection. Without it, any application that crashed or decided to be malicious could corrupt just about anything on the system.

Memory protection is also largely implemented in hardware, and is a fundamental component of how multiple processes can coexist on one computer and still appear to run simultaneously.

That's wayyyyyy different from adding hacks to the kernel to fix broken applications. That reduces kernel quality and encourages app developers to be lazy. It's something Microsoft would do -- add kernel hacks to make Office or Borland work right.

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