My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 77625: Chromium Generates HUGE numbers of CPU wakeups and uses massive amounts of power
79 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  jkummerow@chromium.org
Closed:  Jul 2011
Cc:  vita...@chromium.org, danno@chromium.org, chrome-p...@google.com

Restricted
  • Only users with Commit permission may comment.


Sign in to add a comment
 
Reported by gwh...@kupulau.com, Mar 28, 2011

Chrome Version       : 12.0.717.0 (79524) Ubuntu 11.04
URLs (if applicable) : N/A (but the more tabs you have open, the worse this is)
Other browsers tested: N/A
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
  Firefox 3.x: Does not do this
IE 7/8:

What steps will reproduce the problem?
1. Launch Chromium
2. Open a URL or two
3. Look in powertop, notice that SignalSender is generating a storm of interrupts: 

Top causes for wakeups:
  85.1% (5108.7)   SignalSender

4: Notice that power usage is extremely high
5: Kill Chromium
6: Notice that wakeups return to normal
7: Notice that your laptop is using 20% less power than with Chromium running
8: Launch firefox
9: Notice that it does not generate a storm of wakeups or power

What is the expected result?  Chromium should generate no more wakeups than firefox and should use the same or less power

What happens instead?  Many wakeups and huge power use.


Please provide any additional information below. Attach a screenshot if
possible.

Powertop with Chromium and Firefox running, both with similar tabs open:


Top causes for wakeups:
  88.5% (6074.4)   SignalSender
   1.7% (118.6)   chromium-browse
   1.4% ( 98.8)   plugin-containe
   1.1% ( 73.7)   java
   1.1% ( 72.3)   kworker/0:1
   0.8% ( 52.2)   firefox-bin

(SignalSender is Chromium).

Mar 28, 2011
#1 stuartmorgan@chromium.org
(No comment was entered for this change.)
Labels: -Area-Undefined Area-Internals OS-Linux
Mar 31, 2011
#2 tank.en.mate
My gut feel is that this is the same bug as #77593. The tight loop around nanosleep() will cause approximately 1,100 wake ups per second (one set of these loops per content page plus some constant).
Apr 3, 2011
#3 slowb...@gmail.com
I can verify this issue, getting 30 000 interrupts per second from Chromium "SignalSender", cutting battery life by about 50%....
Apr 6, 2011
#4 thakis@chromium.org
(No comment was entered for this change.)
Status: Duplicate
Mergedinto: 78267
Apr 7, 2011
#5 chaos...@gmail.com
Same here with 12.0.725.0 on Ubuntu 10.10
Apr 7, 2011
#6 nwolov...@gmail.com
Same here.
Ubuntu 10.04/amd64, Chromium 12.0.728.0 (80568)
Apr 8, 2011
#7 krzyszto...@gmail.com
Getting the same here on 12.0.718.0 (0) Built from source for Fedora release 14 (Laughlin)
Apr 8, 2011
#8 chad.a.davis@gmail.com
The number of interrupts appears to be (linearly) proportional to the number of open tabs. The minimum is around 9000 with roughly an additional 1000 per open tab, which I followed by closing tabs one at a time until only this one was left. Restarting Chrome begin with "only" 500 interrupts per second, while on a blank tab, until I reopened this page (only) when it jumped back to 9000 again. For reference, no other process on the system ever exceeds 100 interrupts except possibly if I set the trackpad to maximum sensitivity and move the mouse furiously, I might achieve 300. Thousands per second eats up the battery in no time. 
Apr 12, 2011
#9 maniac...@gmail.com
Same here on Chromium 12.0.728.0 (80568) Ubuntu 10.10

After killing chromium and browsing with firefox the amount of interrupts dropped to sane levels and wattage dropped significantly.
Apr 12, 2011
#10 gwh...@kupulau.com
This is still a problem, even with the fix in place:

12.0.733.0 (81064) 


Top causes for wakeups:
  66.0% (618.4)   SignalSender
  18.3% (171.2)   chromium-browse


Apr 12, 2011
#11 thakis@chromium.org
Unduping. vitalyr, is this likely to be addressed? Seems somewhat important for netbooks.
Status: Untriaged
Cc: vita...@chromium.org
Labels: Stability-Performance
Mergedinto:
Apr 12, 2011
#12 thakis@chromium.org
Reporters: Is this a regression? If so, do you know when this regressed?
Apr 12, 2011
#13 gwh...@kupulau.com
I believe this is related to 78267 - which contains quite a bit of history.
Apr 12, 2011
#14 vita...@chromium.org
Revisions [79379, 80897) are affected by  bug 78267  that prevented the signal sender thread from suspending. After the fix the SignalSender entry in powertop disappears when JS is not active. Do you still have an example where the signal sender significantly changes the distribution of the CPU power states? Note, the total number of wakeups is less important than the actual share of time that the CPU spends in low-power states.
Apr 12, 2011
#15 gwh...@kupulau.com
W/o Chromium:


Cn                Avg residency       P-states (frequencies)
C0 (cpu running)        ( 0.9%)       Turbo Mode     0.6%
polling           0.0ms ( 0.0%)         2.67 Ghz     0.0%
C1 mwait          0.1ms ( 0.0%)         2.53 Ghz     0.0%
C2 mwait          1.8ms ( 2.7%)         2.40 Ghz     0.0%
C3 mwait          9.5ms (96.4%)         1197 Mhz    99.4%

With Chromium:

Cn                Avg residency       P-states (frequencies)
C0 (cpu running)        ( 3.2%)       Turbo Mode     6.2%
polling           3.5ms ( 0.1%)         2.67 Ghz     0.0%
C1 mwait          0.1ms ( 0.2%)         2.53 Ghz     0.0%
C2 mwait          1.1ms (20.4%)         1.60 Ghz     0.1%
C3 mwait          3.2ms (76.1%)         1197 Mhz    93.7%



Apr 12, 2011
#16 gwh...@kupulau.com
That, BTW, is four tabs open - two gmail accounts, twitter and a blank page.

A pretty normal baseline scenario.
Apr 12, 2011
#17 vita...@chromium.org
Thanks for the numbers. But doing something in a browser is supposed to use the CPU, right? Or is your "w/o chromium" actually "with firefox"? We need something to compare the chromium numbers with to declare what you observe a real problem.
Apr 12, 2011
#18 vita...@chromium.org
twitter.com is a highly active page and has timers that update its UI pretty often. (Try running it hitting "Record" in the DevTools Timeline panel.) I just compared the results of opening it in a ToT chromium build and FF3.6 as reported by sudo powertop -p -t 20 -d.

chromium:
Cn	          Avg residency
C0 (cpu running)        ( 1.6%)
polling		  0.0ms ( 0.0%)
C1 mwait	  0.8ms ( 0.8%)
C2 mwait	  1.5ms ( 2.1%)
C3 mwait	  3.4ms (95.5%)

FF3.6:
Cn	          Avg residency
C0 (cpu running)        ( 4.6%)
polling		  0.0ms ( 0.0%)
C1 mwait	  1.3ms ( 0.9%)
C2 mwait	  2.8ms ( 0.9%)
C3 mwait	  6.1ms (93.6%)

Chromium numbers seem to be better. (The results seem pretty stable as well.)

I'm not trying to say power usage is not an important issue and I'm sure that we could do better here. But after the fix in 80897 I think this falls into a category of further enhancements and is not a critical issue. Unless you can provide some counter-example, of course.
Jun 13, 2011
#19 kerz@google.com
(No comment was entered for this change.)
Labels: Internals-Core
Jun 15, 2011
#20 jorge.bi...@gmail.com
Maiores causas de ativações:
  33,0% (753,8)   SignalSender
  21,7% (496,1)   [ath9k] <interrupt>

Linux birck 2.6.38-8-generic #42-Kubuntu 11.04
Jun 20, 2011
#21 alessand...@gmail.com
It's happening to me. Comparing Firefox 4.0.1 and Chromium 12.0.742.100 (both gmail open):

Firefox:
Cn                Avg residency       P-states (frequencies)
C0 (cpu running)        ( 1.2%)       Turbo Mode     0.3%
polling           0.0ms ( 0.0%)         1.74 Ghz     0.0%
C1 mwait          0.2ms ( 0.0%)         1.60 Ghz     0.8%
C2 mwait          0.7ms ( 0.7%)         1466 Mhz     1.0%
C3 mwait         10.8ms (98.1%)         1199 Mhz    97.8%

Wakeups-from-idle per second : 102.3    interval: 15.0s                                                       
no ACPI power usage estimate available

Top causes for wakeups:
  24.3% ( 43.8)   kworker/0:1
  21.0% ( 37.9)   [kernel scheduler] Load balancing tick
  20.2% ( 36.4)   kworker/0:0
   8.5% ( 15.4)   [ehci_hcd:usb1, ath9k, hda_intel, nvidia] <interrupt>
   5.5% ( 10.0)   [kernel core] ath_ani_calibrate (ath_ani_calibrate)
   4.7% (  8.5)   [acpi] <interrupt>
   4.5% (  8.2)   [kernel core] hrtimer_start (tick_sched_timer)
   3.7% (  6.7)   firefox
   2.2% (  3.9)   [ahci] <interrupt>
   2.2% (  3.9)   plasma-desktop
   0.6% (  1.1)   sensors
   0.6% (  1.1)   kwin
   0.6% (  1.0)   kworker/u:4

Chromium:
Cn                Avg residency       P-states (frequencies)
C0 (cpu running)        ( 2.7%)       Turbo Mode     0.3%
polling           4.3ms ( 0.1%)         2.40 Ghz     0.0%
C1 mwait          0.1ms ( 0.1%)         1466 Mhz     0.0%
C2 mwait          1.0ms ( 6.9%)         1333 Mhz     0.0%
C3 mwait          4.3ms (90.2%)         1199 Mhz    99.6%

Wakeups-from-idle per second : 290.1    interval: 15.0s                                                       
no ACPI power usage estimate available

Top causes for wakeups:
  30.5% (147.8)   chromium
  29.3% (142.0)   SignalSender
  12.8% ( 62.1)   kworker/0:1
   9.1% ( 44.3)   [kernel scheduler] Load balancing tick
   6.8% ( 33.0)   kworker/0:0
   3.0% ( 14.7)   [ehci_hcd:usb1, ath9k, hda_intel, nvidia] <interrupt>
   2.1% ( 10.0)   [kernel core] ath_ani_calibrate (ath_ani_calibrate)
   1.7% (  8.1)   [acpi] <interrupt>
   1.7% (  8.0)   [kernel core] hrtimer_start (tick_sched_timer)
   0.8% (  4.1)   plasma-desktop
   0.8% (  3.7)   [ahci] <interrupt>
   0.2% (  1.2)   krunner
   0.2% (  1.1)   kwin
Jun 21, 2011
#22 therap...@gmail.com
Aha, this is why my laptop has the heating properties of an iron...
Jun 23, 2011
#23 a...@fractal9.net
Same here with Chromium 14.
Chromium eats approx 1W more than Firefox. Almost twice as many wakeups/s.
(Three tabs open, 1 GMail + 2 static pages).

A) Firefox 3.6.17:

  Cn                Avg residency
  C0 (cpu running)        ( 5.0%)
  polling           0.0ms ( 0.0%)
  C1 halt           0.0ms ( 0.0%)
  C2                0.3ms ( 1.2%)
  C3                2.6ms (93.8%)
  [...]
  Wakeups-from-idle per second : 408.9    interval: 20.0s
  Power usage (ACPI estimate): 14.2W (1.6 hours)
  Top causes for wakeups:
    29.4% (143.7)   [      ] [extra timer interrupt]
    19.8% ( 96.8)   [  7111] plugin-containe
    19.1% ( 93.5)   [      ] [Rescheduling interrupts] <kernel IPI>


B) Chromium 14.0.797.0

  Cn                Avg residency
  C0 (cpu running)        ( 9.8%)
  polling           1.6ms ( 0.1%)
  C1 halt           0.0ms ( 0.0%)
  C2                0.4ms ( 6.5%)
  C3                1.5ms (83.6%)
  [...]
  Wakeups-from-idle per second : 754.8    interval: 20.0s
  Power usage (ACPI estimate): 15.3W (1.5 hours)
  Top causes for wakeups:
    29.1% (293.4)   [      ] [extra timer interrupt]
    25.7% (259.1)   [      ] SignalSender
    14.4% (145.2)   [      ] chrome

Jul 4, 2011
#24 vita...@chromium.org
https://code.google.com/p/v8/source/detail?r=8472 should improve the situation. I'm not sure when it's going to be in chromium.
Status: Assigned
Owner: vita...@chromium.org
Jul 5, 2011
#25 fishd...@gmail.com
Confirm on chromium-browser-12.0.742.91~r87961-0ubuntu0.11.04.1.

Does _not_ happen with google-chrome-stable (12.0.742.112-r90304)
Jul 5, 2011
#26 hor...@gmail.com
Confirmed on 12.0.742.112 (90304) Ubuntu 11.04 (12.0.742.112~r90304-0ubuntu1~ucd~stable1~natty from LP-PPA-chromium-daily-stable)
Jul 5, 2011
#27 f...@soundcloud.com
Sorry, cofnrimed on offical google-chrome build too, but looks like i happens only after loading the first javascript.
Jul 8, 2011
#28 Ganum...@gmail.com
confirmed for chrome 12.0.742.112 in
ubuntu 11.04
ubuntu 10.10 

Jul 17, 2011
#29 david8bl...@gmail.com
confirmed for ubuntu 10.04. chromium 12  with just one tab of a google search open. never saw this in previous versions.

Wakeups-from-idle per second : 391.4	interval: 15.0s
no ACPI power usage estimate available
Top causes for wakeups:
  87.3% (1362.7)   SignalSender
   4.8% ( 75.3)   [kernel scheduler] Load balancing tick
   2.6% ( 39.9)   LCDd
   2.4% ( 37.9)   chromium-browse

Jul 19, 2011
#30 evan@chromium.org
It sounds like this was fixed in late June.  If anyone can test this in recent version of Chrome (like 14.0.825.0 or so) and let us know if it's fixed, it would help.
Jul 20, 2011
#31 pat...@gmail.com
It is better with 14.0.817.0:

Top causes for wakeups:
  32.8% (705.3)   [extra timer interrupt]
  27.9% (600.4)   SignalSender
  17.9% (386.2)   PS/2 keyboard/mouse/touchpad interrupt
   7.5% (160.7)   [Rescheduling interrupts] <kernel IPI>
   6.6% (141.7)   chromium-browse
   1.5% ( 32.6)   Xorg
Jul 28, 2011
#32 r.deepak...@gmail.com
Confirmed that this problem existed for me. It has improved tremendously with 14.0.835.0
Jul 29, 2011
#33 elan.ruu...@gmail.com
looks good no more SignalSender in top,

chromium-browser 15.0.838.0, svn r94616

Top causes for wakeups:
  38.1% (295.5)   [Rescheduling interrupts] <kernel IPI>
  21.6% (167.7)   kworker/0:0
   8.8% ( 68.4)   PS/2 keyboard/mouse/touchpad interrupt
   7.5% ( 58.0)   [kernel scheduler] Load balancing tick
   6.6% ( 51.2)   [ata_piix] <interrupt>
   3.8% ( 29.6)   chromium-browse
   2.9% ( 22.1)   Xorg
   2.5% ( 19.4)   [iwl3945] <interrupt>
   1.6% ( 12.7)   [kernel core] cfq_completed_request (cfq_idle_slice_timer)
   1.3% ( 10.3)   nautilus
   0.9% (  6.9)   [kernel core] hrtimer_start (tick_sched_timer)
   0.7% (  5.1)   SignalSender
   0.6% (  4.9)   syndaemon
   0.5% (  4.0)   [kernel core] usb_hcd_poll_rh_status (usb_add_hcd)
   0.5% (  3.6)   kworker/u:4
   0.2% (  1.7)   [nvidia] <interrupt>
   0.2% (  1.6)   gnome-terminal
   0.1% (  1.0)   gvfs-afc-volume
   0.1% (  0.9)   [kernel core] sk_reset_timer (tcp_keepalive_timer)
   0.1% (  0.9)   xfsbufd/dm-0
   0.1% (  0.9)   xfsbufd/dm-1
   0.1% (  0.8)   xfsbufd/dm-5
   0.1% (  0.7)   [Function call interrupts] <kernel IPI>
   0.1% (  0.7)   [TLB shootdowns] <kernel IPI>
   0.1% (  0.7)   watchdog/0
   0.1% (  0.6)   [Non-maskable interrupts] <kernel IPI>
   0.1% (  0.6)   snmpd
   0.1% (  0.6)   hald-addon-stor
   0.1% (  0.5)   dropbox
   0.1% (  0.5)   udisks-daemon
   0.1% (  0.4)   gnome-settings-

Jul 29, 2011
#34 evan@chromium.org
Marking fixed unless Vitaly would like to leave it open for any reason...
Status: Fixed
Jan 7, 2012
#35 ori...@gmail.com
I'm still getting the same results with 15.0.874.106 (Developer Build 107270) Ubuntu 11.10.
This is what powertop shows with only this tab open:

                Usage       Events/s    Category       Description
              1.0 ms/s     166.6        Process        /usr/lib/chromium-browser/chromium-browser
              6.0 ms/s      71.7        Timer          hrtimer_wakeup
            642.2 µs/s       3.6        Process        /usr/lib/chromium-browser/chromium-browser --type=extension --lang=en-US --force-fieldtest=ConnCountImpact/conn_count_6/Connn
            306.5 µs/s       1.5        Timer          tick_sched_timer

it looks the same even when I close all tabs and leaving only empty tab.

Feb 26, 2012
#36 simonbro...@gmail.com
Why is this marked as fixed? The issue is still present on the very latest Chrome builds... 8W Chrome vs. 6W Firefox.

Have the changes not been merged into Chrome yet?
Feb 26, 2012
#37 vita...@chromium.org
(No comment was entered for this change.)
Owner: danno@chromium.org
Feb 27, 2012
#38 danno@chromium.org
Jakob, keep this in mind with your changes to the profiler, and please verify that we haven't regressed.
Owner: jkummerow@chromium.org
Cc: danno@chromium.org
Feb 27, 2012
#39 jkumme...@google.com
@36: It's marked fixed because the issue was that "SignalSender" would generate thousands of CPU wakeups per second (see e.g. comment #8). That is no longer the case: Even with >20 tabs open, SignalSender triggers 50-150 interrupts per second (Chrome 18.0.1025.39 beta).
If there is in fact a power usage difference between Chrome and Firefox currently, it must be due to some other reason.
Feb 27, 2012
#40 simonbro...@gmail.com
Any idea how to pinpoint the culprit? I have a feeling opening a new issue won't help much...

Are you seeing power consumption that's on par with Firefox? Because Chrome 17.x is still higher by about 2-3W.
Feb 27, 2012
#41 jkummerow@chromium.org
For me, the difference in battery power draw between idle and having Firefox open with one GMail tab is about 900mA and seems to be pretty stable, whereas Chrome's power draw jumps up and down between roughly 500 and 900mA, so if anything it appears to be a tad better.

To narrow down the cause, you can disable all plugins (chrome://plugins) and extensions (chrome://extensions) and see if that makes a difference. If it does, enable them one by one to see which one triggers it.

What does powertop report for you?
What hardware do you have?
Feb 27, 2012
#43 simonbro...@gmail.com
Unfortunately, I don't have access to Powertop, as I only run Windows. The figures I'm reporting are mostly from Lenovo's Thinkvantage Power Manager. Running a Thinkpad X200 with Windows 7... issue is the same on an R61 and a T410.

As far as I can tell, opening Chrome stops the CPU from entering C4 sleep.


On the X200:
http://dl.dropbox.com/u/7086491/pictures/browserpowerconsumption/chrome.gif
http://dl.dropbox.com/u/7086491/pictures/browserpowerconsumption/firefox.gif



I'll give disabling the plugins a shot, thanks for the tip. I'm putting my money on Flash... grrr.


-edit- Unfortunately, the only three extensions I can disable are the ones I've installed - and I've already verified that Chrome's power consumption doesn't change due to these. Is there a way to disable components that come with the browser? Such as Flash?
Feb 27, 2012
#44 jkummerow@chromium.org
Flash is a plugin, not an extension. It can be disabled at chrome://plugins.

My Thinkpad T400 spends >90% of its time in C4 sleep with Chrome running.
Feb 27, 2012
#45 simonbro...@gmail.com
Looks like it really comes down to Flash.

Test:

1. Disabled all plugins in chrome://plugins
2. Restarted Chrome
3. Opened my usual background tabs

Low power consumption

4. Reenabled Flash plugin
5. Reloaded the one site that uses Flash (imo.im), with the FlashBlock extension enabled

High power consumption


Looks like I'm stuck with Firefox for the time being. Flash uses a lot of power there too, but FlashBlock stops this from happening until you actually manually activate a Flash element fully. Not so on Chrome, apparently... Any bright ideas? :)
Feb 27, 2012
#46 jkummerow@chromium.org
Go to chrome://settings/content (or Wrench > Options > Under the Hood > Content Settings, if you like clicking), set Plugins to "Click to play".

Then uninstall FlashBlock, as it's no longer needed.
Feb 27, 2012
#47 simonbro...@gmail.com
Looking much better already, thanks. Still not quite on par with Firefox (which reliably stays under 7W if I don't load any new pages), with spikes up to 8W, but definitely usable.

Thanks for the quick help and your patience!
Oct 13, 2012
#48 bugdro...@chromium.org
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Labels: Restrict-AddIssueComment-Commit
Mar 10, 2013
#49 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-Internals -Stability-Performance -Internals-Core Cr-Internals Performance Cr-Internals-Core
Sign in to add a comment

Powered by Google Project Hosting