User: Password:
Subscribe / Log in / New account



Posted Aug 6, 2010 0:25 UTC (Fri) by caliloo (subscriber, #50055)
In reply to: Whack-a-droid by marcH
Parent article: Whack-a-droid

I meant energy is now a resource in the same sense that memory and cpu time are. Critical for usability, easy to ruin by non versed programmers if let completely free for access. You have to police -somewhat- its use, like cpu and mem are.
By raising such safety handrails near the cliff edge, you lower the barrier of entrance for new programmers on your platform, they have less to learn.

Who cares now of real to virtual memory translation amongst the app developpers ? not many people.

Who cares of releasing the CPU in a non interactive batch script. Not many people now.

Well it'd be nice if the same could apply to energy, in my opinion.

(Log in to post comments)


Posted Aug 7, 2010 16:17 UTC (Sat) by ldarby (guest, #41318) [Link]

What do you mean, that it'd be nice if devs don't have to care about how much energy the apps use?

I think it's sad that some devs no longer care about resource usage, the applications end up being slow, no matter how much hardware or OS memory management you throw at it. So letting people not care about energy usage is going to lead to more energy usage, therefore I think the PowerTop approach of naming & shaming is the only one that works in the long term.


Posted Aug 9, 2010 15:23 UTC (Mon) by caliloo (subscriber, #50055) [Link]

What I meant, is that they should only care about energy if it becomes a problem, and when it becomes a problem, it shouldn't bring the system down.

I fully agree with the policy of Naming and Shaming. My point though, is that instead of bringing the whole system down with it, the "bad" app should be ruthlessly killed/throttled by the OS before it becomes a problem for other apps that are well mannered and the platform as a whole.

Make the parallel with memory management. If an app is buggy/badly written, it shouldn't destroy the system it sits on. Managing the energy at OS level means that a buggy app is contained in it's own realm (with say, a max energy budget), and only brings that down with it. Then people can really start Naming and Shaming. It makes pinpointing and fixing problems easier.

On the other hand, if you keep the power top approach, you have to have educated users (scarce resource) pinpointing problems, after the system has crashed already once. (people don't look for problems they don't see).

Energy accounting like in Powertop is good, but not enough. You need to be able to the capacity to constrain it, limit its use. You don't want the worry of a 3rd party buggy app going into a infinite active loop or other similar things when you sell a phone.

So yes ! Name and Shame ! But also try hard to limit the damage those bad apps can do.


Posted Aug 16, 2010 8:17 UTC (Mon) by marcH (subscriber, #57642) [Link]

The analogy is nice but has a number of problems.

It is true that today one application cannot instantly bring the whole system down by locking up the CPU or by corrupting memory, however today by default one application can still exhaust memory or CPU. Surprise, surprise, energy "management" is not lagging behind but in the *exact same state* already today! Actually not that a big surprise since energy use is more or less a consequence of CPU use.

So the "bounded energy budget" you are describing goes further than today's default CPU or memory management. And it would still not prevent one application from (slowly) draining the battery out.

One last word about the intimate relation between CPU and energy: you could imagine that policing energy is actually not required, policing CPU being enough. Just rename "wakelocks" to "CPUlocks" and stop the scheduler when no CPUlock is grabbed. Then suspend on a timeout as usual. This is simplified but you get the idea: energy is not a "first-class" citizen like memory or CPU.

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