Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for June 20, 2013
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
I thought that all parties involved basically agreed on this and on all the other goals you mentioned, disagreeing only on *how* to get there.
Are you saying that some dark forces try to stop any kind of progress?
Posted Aug 6, 2010 0:25 UTC (Fri) by caliloo (subscriber, #50055)
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.
Posted Aug 7, 2010 16:17 UTC (Sat) by ldarby (subscriber, #41318)
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)
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)
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 © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds