Whack-a-droid [LWN.net]

By Jonathan Corbet
August 3, 2010

Paul McKenney, it seems, is now working with the Linaro project, an assignment which has given him a new interest in power management. He has decided to start off with a bang by attempting to summarize the suspend blocker discussion with the goal of really understanding what Android's requirements are. Needless to say, he has kicked off a new, lengthy discussion which has cast the players' positions in a new light.

To oversimplify: one side seems to believe in addressing power management (and poorly-behaving applications in particular) by shining a light on the problems and fixing them (or applying social pressure to get them fixed) one at a time. This is the approach taken by developers like Arjan van de Ven, who have developed and used tools like PowerTop to great effect. The other side pushes for a more general solution; Paul describes the difference in view this way:

I agree that much progress has been made over the past four years. My laptop's battery life has increased substantially, with roughly half of the increase due to software changes. Taken over all the laptops and PCs out there, this indeed adds up to substantial and valuable savings.

So, yes, you have done quite well.

However, your reliance on application-by-application fixes, while good up to a point, is worrisome longer term. The reason for my concern is that computing history has not been kind to those who fail to vigorously automate. The Android guys have offered up one way of automating power efficiency. There might be better ways, but their approach does at the very least deserve a fair hearing -- and no one who read the recent LKML discussion of their approach could possibly mistake it for anything resembling a fair hearing.

So far, the conversation has not yet really returned to the Android approach; it has stayed more focused on the requirements and whether the "whack-a-mole" approach to power management is sufficient in the long term. Chances are good that Paul will be sending out an updated version of his requirements description sometime in the near future. Then, perhaps, there can be a calm discussion of how those requirements might best be satisfied.

Index entries for this article
Kernel	Power management/Opportunistic suspend

to post comments

Whack-a-droid

Posted Aug 5, 2010 3:22 UTC (Thu) by caliloo (subscriber, #50055) [Link] (11 responses)

Back in the days, some people invented virtual memory. They did it partly because some other guys were not able to write proper apps, and the first guys just had enough to see their whole box fail because of some random crappy segfaults they had no control on.

Now memory is a well managed resource. Every app is rigidly penned in it's own little garden. And all is kinda well.

Today a new resource comes to light as critical for the good working of a box. Energy. I don't see why we shouldn't go and do the same: forcefully police its use within the system, don't let random crap ruin the day.

You can also do the same kind of comparison with multitasking for the attribution of cpu time. Before there wasn't any and life was hard. Then they invented cooperative multitasking, that was much better. Then went to preemptive multitasking, just because life was even easier that way.

Let's face it: energy is _now_ a resource. That's a big part of what hosting companies base their bills on. It's what makes a mobile device relevant. It wasn't always that way, but now it is. Linux has to adapt one way or other or become irrelevant.

Whack-a-droid

Posted Aug 5, 2010 9:47 UTC (Thu) by xav (guest, #18536) [Link] (5 responses)

The problem with this example s that Linux is quite bad at managing virtual memory. Try to use your desktop with a big memory hog, when the disk grinds continually and the mouse pointer doesn't even move anymore, and you'll see that arbiting resource-hungry processes is still not done.

Whack-a-droid

Posted Aug 5, 2010 13:26 UTC (Thu) by etienne (guest, #25256) [Link] (4 responses)

Not being a specialist, I would say that managing 1,048,576 pages (a desktop with 4 Gb of memory on i386) inevitably takes time.
Switching to all pages of 2 Gbytes (as the only other solution on ia32) is not really possible (most filesystems have pages of 4 Kbytes).
Is there another OS which better manages this amount on pages (on the same hardware), or is it a microprocessor problem and other processor having pages of 64Kbytes (or variable size pages) are the solution?

Whack-a-droid

Posted Aug 6, 2010 10:11 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (3 responses)

The problem is not that there are a lot of pages to manage. The problem is that application developers, no longer being forced to care about using memory efficiently, have stopped caring about using memory efficiently.

It's further exacerbated by all those exciting, easy-to-learn-to-use dynamic languages that sweep all memory management complexity under someone else's carpet, more or less entirely destroying programmers' ability to intuit or reason about the memory usage of their program.

Whack-a-droid

Posted Aug 6, 2010 10:44 UTC (Fri) by modernjazz (guest, #4185) [Link]

Anyone who lived with the Mac classic environment for a while can tell you that managed memory is nice. In practice, the segfaults never all get fixed.

It was especially awful when the segfaults were my own, because I'd have to reboot the computer 50 times a day when writing and testing my own code. Development became oh-so-much-nicer when I switched to Linux, and I just got the "Segfault" on the command line rather than "beep-reboot." Either way I fixed the problem, but with Linux I didn't spend half the day waiting for the computer to come up.

It's a bit different with power management. In a way, I think policy might be even more important in this case: the developer may not notice or immediately suffer from power management problems in the same way that the developer him/herself suffers from memory errors. So the incentive of someone who has just developed some mobile app to fix the problem may not be as high as you'd like. Do you really want to spend your whole life acting as a cop and beating on people to fix their code? There's not enough time for code review as it is.

Whack-a-droid

Posted Aug 6, 2010 13:01 UTC (Fri) by etienne (guest, #25256) [Link]

Well, I was replying to xav who seems to have a test case which is a lot quicker on other Unix systems.
I can imagine that having a database with 2 Gbytes data to manage would need quite a bit of virtual memory even if it is correctly written.
If that application recompiled for the other Unix is definitely quicker, it may be due to the too small granularity of the pages on ia32, forcing the same treatment (for instance write of copy-on-write pages) to be done hundred of thousands of times.
Even if the code is optimised, it will be slow.
The nice thing of 4 Kbytes memory pages is that the filesystem code (which has 4 Kbytes blocks) is simpler (things like paging-in memory mapped files on read).
Would be nice to know if another Unix on ia32 processor is quicker, or simply another processor is quicker on the test case.
But as I said, I am not a specialist of virtual memory.

Whack-a-droid

Posted Aug 13, 2010 15:19 UTC (Fri) by renox (guest, #23785) [Link]

I would add that it is *also* partly the kernel's fault of not providing a way for the virtual memory manager to work with the garbage collector..

Otherwise when a programmer fails to release memory correctly only swap could be used instead of memory (as happen usually in language without garbage collector: old unused pages are swapped to the disk) see:
http://lambda-the-ultimate.org/node/2391

Whack-a-droid

Posted Aug 5, 2010 23:37 UTC (Thu) by marcH (subscriber, #57642) [Link] (4 responses)

> Let's face it: energy is _now_ a resource.

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?

Whack-a-droid

Posted Aug 6, 2010 0:25 UTC (Fri) by caliloo (subscriber, #50055) [Link] (3 responses)

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.

Whack-a-droid

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

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.

Whack-a-droid

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

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.

Whack-a-droid

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.

Whack-a-droid

Posted Aug 5, 2010 5:08 UTC (Thu) by alonz (subscriber, #815) [Link] (3 responses)

Of course, the updated "attempt at summary of suspend-blockers thread" from Paul came out just after the LWN edition...

Whack-a-droid

Posted Aug 5, 2010 19:40 UTC (Thu) by maney (subscriber, #12630) [Link]

Ah. "There is no Cabal." :-)

Whack-a-droid

Posted Aug 19, 2010 18:36 UTC (Thu) by oak (guest, #2786) [Link] (1 responses)

"It would be nice to be able to identify power-oblivious applications that never were depended on by PM-driving applications."

Would it be enough to identify it as a bad app, for example when it tried to update the display although screen was blanked? This could be done in the user-space graphics stack...

Whack-a-droid

Posted Aug 25, 2010 21:18 UTC (Wed) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

It could be thought of as an independent application. In other words, sending it a SIGSTOP would have no effect on any other application or on the system infrastructure.