poor battery performance in Unity

Reported by Jonathan Jesse on 2010-06-28
50
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Unity
Critical
Neil J. Patel

Bug Description

The battery life on my Netbook is being eaten up by the new update. I think the problem is the index is being built on battery and decreasing the time I have on battery.

Updated on power, had a full charge, unplugged to go watch TV and logged into new Unity. Within 10 minutes I was at 1/2 battery life and 10 minutes later was done to 3/4 battery. Seems like an index was being built for the first time you use the search (zeitigest I think the application is called). Would be nice if there was a way to configure indexing on battery life.

RUnning a Dell Mini 9 w/ 10.04 completly up to date. 1 GB of RAM on my netbook

Related branches

Neil J. Patel (njpatel) wrote :

Hi, thanks for reporting the bug. I had a couple of questions:

1. Does the performance issue still occur when you log into Unity?
2. Did you run top at the time? What were the processes with the highest cpu usage if so?
3. Can you mv ~/.local/share/zeitgest ~/.local/share/zeitgeist.backup and then re-login and see if you get the same issues (as zeitgeist will rebuild it's index).

We don't do any content-level indexing, only index the filenames and paths of what's in your recently-used cache, I wouldn't expect zeitgiest to eat CPU like this, so definitley something is going wrong. I''ll mark as incomplete pending the information.

Changed in unity:
assignee: nobody → Neil J. Patel (njpatel)
importance: Undecided → High
milestone: none → 2010-07-01
status: New → Incomplete

I am very hesitant to conclude that Zeitgeist eats your battery. It doesn't do any file system crawling and the indexing it does is extremely light. If you start up without any prior Zeitgeist you .recently-used.xbel will be scanned and indexed and that's all. On a netbook I'd expect this to take ~10s if you have a very long history.

However there are lots of other new technologies landing in Unity so there are many places to look.

Have you tried using the tool 'powertop'? Just 'apt-get install powertop' and then run 'sudo powertop' and see which process is eating your battery. For me here it's pretty much always Firefox. Especially when I have lots of Flash apps loaded...

Jonathan Jesse (jjesse) wrote :

Thanks guys for the help, will be attaching a screenshot, dont know what exactly was causing the battery drain. was at 52% of battery life when I loggeed in and while I was posting this bug it was down to 43%.

Not quite sure what is going on

Hope you can see what is going on

It worries me a bit to see desktop couch in there. I have the same picture here more or less. Thanks for providing this Jonathan - I'll see if I can round up someone who has a bit of insight on this.

Mirco Müller (macslow) on 2010-07-02
Changed in unity:
milestone: 2010-07-01 → 2010-07-08
Jonathan Jesse (jjesse) wrote :

alrighty updating this bug as i did a fresh install of maverick today and still having some performance problems. the systems to respond slowly to me, especially switching from window to window.

hope i'm helping out

Hernando Torque (htorque) wrote :

I'm not having a battery and I don't see desktop-couch causing that many wake-ups, but I do see mutter randomly hogging the CPU for no apparent reason (causing up to 100% load). It usually happens when starting programs or switching between windows and stops when closing a couple of programs. I also had the system in a state where just moving the mouse caused mutter to spike between 50 and 80 % CPU load - I'm sure all that can drain a battery pretty fast.

Neil J. Patel (njpatel) on 2010-07-12
Changed in unity:
milestone: 2010-07-08 → 2010-07-15
Neil J. Patel (njpatel) on 2010-07-16
Changed in unity:
milestone: 2010-07-15 → 2010-07-22

Please don't keep deferring this. We have a real problem, we need to
address it sooner rather than later.

Mark

Jonathan Jesse (jjesse) wrote :

hey guys i've been on the road and forgot my mini so i'm hoping things
changed while i was on the road. will do some updates when i return tonight
and update to see how this works. what do i need to do to help out?

On Fri, Jul 16, 2010 at 7:23 AM, Mark Shuttleworth <
<email address hidden>> wrote:

>
> Please don't keep deferring this. We have a real problem, we need to
> address it sooner rather than later.
>
> Mark
>
> --
> poor battery performance in Unity
> https://bugs.launchpad.net/bugs/599425
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Unity: Incomplete
>
> Bug description:
> The battery life on my Netbook is being eaten up by the new update. I
> think the problem is the index is being built on battery and decreasing the
> time I have on battery.
>
> Updated on power, had a full charge, unplugged to go watch TV and logged
> into new Unity. Within 10 minutes I was at 1/2 battery life and 10 minutes
> later was done to 3/4 battery. Seems like an index was being built for the
> first time you use the search (zeitigest I think the application is
> called). Would be nice if there was a way to configure indexing on battery
> life.
>
> RUnning a Dell Mini 9 w/ 10.04 completly up to date. 1 GB of RAM on my
> netbook
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/unity/+bug/599425/+subscribe
>

Gord Allott (gordallott) wrote :

Did basic testing throughout the weekend, using latest maverick updates. On my mini 10v.
cpu usage is much lower than it was previously and i can't actually get it to raise to a high value again.
cpu usage hovers around 2%, which is about 0.5% higher than mutter sans unity.
indicators were factored out of the equasion, as were effects. In the end we ran a script to open and close windows often over a large period of time but still we hover around a small %cpu value.

Still needs investigation but would like to hear if this is still a problem, Thanks

Mark Shuttleworth (sabdfl) wrote :

I can get mutter to jump to 30-40% cpu utilisation for a few seconds,
just by moving the mouse over it.

Mark

Neil J. Patel (njpatel) wrote :

Mark, are you using Lucid or Maverick? We know this is a problem on Lucid Intel, and it seemed to be an issue on Maverick Intel until the latest round of updates. Can someone with Maverick please test on a fully updated Maverick machine to see if the issue is still happening. Our testing has been on Intel i945 netbooks (the lowest graphics we support), i965, as well as testing nvidia systems (which don't seem to suffer from it).

In addition to this, we've got the latest Clutter and Mutter updates arriving this week so we would appreciate continued testing of this issue.

Finally, with the latest updates on i965, I see the following and would like some confirmation:

1. A maximised terminal running top is giving me a Xorg and Mutter CPU usage of 1-3% (normally 1-2.
2. From position 1. , running my mouse over, really quickly, on the panel horizontally, is giving me a CPU usage spike to ~10%
3. From position 1. , running my mouse over, again very quickly, the launcher vertically is giving me a CPU usage spike to 40% (I think this is what you were mentioning Mark).

I will investigate the painting spikes of 2 & 3 further tomorrow morning with Gord.

Neil J. Patel (njpatel) wrote :

Okay, for point 3, it seems if we don't show the quicklists, I can't get Mutter to take over 15% CPU usage when violenting moving the mouse over the launcher. I would hazard a guess that the active blur behind the quick-lists is causing an issue on these chips. I'm going to see what else I can disable that effects the painting CPU usage.

Neil J. Patel (njpatel) wrote :

I disabled the launcher entirely and still managed to get Mutter's CPU usage to 13% with mouse-over on the area the launcher would be, which seems to indicate that all this is tied to the input region.

I therefore disabled the in put region (while the panel and launcher still painted/updated through their models) and boom, CPU usage never spilkes above 3%.

So, it seems that there is some foul-play happening between the painting during mouse-events in the input region of mutter compared to the when the mouse is moving in the region of the screen where mutter is not receiving events (and therefore only processing some launcher/panel events, but mostly texture-from-pixmap events through X). This is why we can make mouse-movements on the panel (which has *no* roll over states) spike CPU to 10%. it's obviously causing a paint for no reason.

Will look in more depth at this tomorrow (although please still provide your results).

Neil J. Patel (njpatel) wrote :

Aaaand finally, as a bid you good night, I shall leave you with these delightful chunk of information:

The CPU usage spikes for input *must* be coming from Clutter's picking mechanism, which uses glReadPIxels to figure out where everything is. It's the only conceivable reason why i can think that scrubbing over the panel would effect CPU usage. It happens on `unity -p` as well, so should be easier to debug.

Neil J. Patel (njpatel) on 2010-07-19
Changed in unity:
importance: High → Critical
status: Incomplete → In Progress
Mark Shuttleworth (sabdfl) wrote :

Momentary CPU usage when we are actually influencing the launcher /
panel rendering is fine. In other words, if I move the mouse over the
launcher and the app icons dance, it's OK for that to use the CPU. In
fact, use it hard, make it stunning, show off the hardware.

What's unacceptable is if the CPU *stays* utilized even when I'm not
"working with Unity". I don't think people will be reporting low battery
life because of CPU burning while they are playing with the launcher -
they are concerned about Unity burning the cpu when they are spending
all day in the browser or other applications.

I'll upgrade to Maverick today and see if the issue is resolved. It's
fine if it works on Maverick.

Mark

Omer Akram (om26er) wrote :

I have rhythmbox, chromium, nautilus, evolution and gwibber running but the mutter cpu usage is 2-4% but if I start xchat mutter's cpu usage does not fall from 15% constantly.

switching between apps spike mutter usage to 20% by alt+tab and 30+% by using mouse. Playing a video song in Totem causes mutter to ~45%

Neil J. Patel (njpatel) wrote :

Mark, agreed, but 40% is too much for motion events (the launcher wasn't moving or unfolding, as it had already unfolded, this was caused by the hit-detection in Clutter).

So, we've been working together on this yesterday and today, and here's an update:

 - Motion event hit-detection in Clutter (using glReadPixels) is the cause of the mouse issues. Jason is working on a patch to simplify the hit detection. Hopefully this will work and visibly increase the performance of Clutter on netbooks

- Idle CPU usage. This is caused by Clutter not properly supporting sub-region updates, and Unity painting a lot of things. Gord is working on implementing a proof-of-concept idea to see if we can solve this in a clever way for Unity.

If we get some positive results, we hope to have these in for Alpha 3.

Mark Shuttleworth (sabdfl) wrote :

OK, thanks Neil.

Neil J. Patel (njpatel) wrote :

Alrighty, #2 proof-of-concept worked, so we'll start implementing that for A3. Idle CPU usage reduces down to Mutter without the Unity plugin, so 7% with Totem, 1-2 % with X-chat and 0-1% with nothing (on Intel i945, Maverick).

Mark Shuttleworth (sabdfl) wrote :

Good to hear!

Mark Shuttleworth (sabdfl) wrote :

I think it would also be worth looking at PowerTOP to check that we
aren't triggering unnecessary wakeups, too. Also, look at how we're
scheduling wakeups to make sure we cluster them together.

FR. Loïc (hackurx) wrote :

Use Openbox as window manager in Gnome could save the battery and make quick viewing on our netbook. What do you think of this idea?

David Barth (dbarth) on 2010-07-26
Changed in unity:
milestone: 2010-07-22 → 2010-07-29
Neil J. Patel (njpatel) wrote :

Sorry for the lack of updates, we've been busy trying to implement the ideas mentioned above. The current status is:

- We've merged in the work to work around Clutter wanting to paint everything, every cycle, so there should be a big improvement in this week's release of Unity. The difference we get is a drop from 40-50% with Totem playing to 10-12% (expected, as we're actually rendering Totem's window too). We hope to make this even better with some more work on what paints every cycle. On idle, CPU usage should have now dropped down to 0-1% (depending on if the system is actually idle, no blinking cursors!)

- Our work on removing the use of glReadPixels from Clutter for Unity is mostly complete and will land in Maverick this week. This will make general performance when using Unity components much better

- Running with PowerTop, Unity is not suffering from excessive wakeups

- Finally, we hope to continue optimizing the netbook case of maximised windows (making sure things underneath aren't painting). Mutter already does some of this, but we hope to optimize further.

zp (zekopeko) wrote :

@Neil

What is a reasonable number of wakeups?

Neil J. Patel (njpatel) wrote :

@zekopeko Well, none when your not doing any work :) Unfortunately, unless your desktop is completely idle (nothing changing) the compositor is at least painting the screen. In my tests (and these are on-going with every release), we don't wake up on a completely idle desktop.

With a blinking terminal window and a changing indicator (say sound, network and messages), Mutter (with unity plugin) doesn't register on PowerTop at all.

Finally, with youtube playing video, mutter's process comes in at 0.5-3% wakeups, with chromium and npviewer.bin (which contains flash) coming in at 10+% wakeups each (on my Intel i965). I think this is pretty good for a gl compositor, though I need to do some more thorough tests when I get home.

Again, we still want to improve further, but currently the focus is on idle CPU usage and CPU usage when playing videos (which is work to workaround Clutter's paint cycle).

David Barth (dbarth) on 2010-08-04
Changed in unity:
milestone: 2010-07-29 → 2010-08-05
David Barth (dbarth) on 2010-08-09
Changed in unity:
milestone: 2010-08-05 → 2010-08-19
Mark Shuttleworth (sabdfl) wrote :

Ftr, this is greatly improved in 0.2.24

Neil J. Patel (njpatel) wrote :

The last bits of this bug are in from this week's release.

Changed in unity:
status: In Progress → Fix Committed
Hernando Torque (htorque) wrote :

With 0.2.28 I'm still seeing CPU thrashing (constant 50+% load for mutter) with a couple of maximized windows opened (usually a mix of GNOME Terminal, Opera, Chromium, XChat, Thunderbird, and gedit), that ends with unmaximizing or closing one or more of those windows.

Using nvidia-current 256.44 with a nVidia GeForce 6600 GT (NV43).

Neil J. Patel (njpatel) on 2010-08-20
Changed in unity:
status: Fix Committed → Fix Released
Hernando Torque (htorque) wrote :

FWIW: I've been running 12 maximized windows the last hour without any resource problems using the Nouveau drivers from xorg-edgers PPA, so what I'm seeing could be a Nvidia BLOB related problem. On the other hand, I'm not getting "the real deal" with those drivers*, so it could also just be coincidence.

*) The launcher is garbled, some top panel items are missing, and the desktop area shows artifacts every once in a while (see screenshot). Plus, I cannot go above the 1024*768 resolution because my monitor's EDID is broken and Nouveau doesn't support external EDID (but that's another story :-)).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions