[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 10:44 AM, Peter Kasting wrote: > On Tue, Jul 14, 2009 at 5:53 AM, Joel Stanley wrote: >> >> So we do this for GIFs. Can anyone tell me if background tabs >> re-paint themselves? If not, I'll add it to the TODO. > > IIRC renderers don't actually paint until the browser tells them to. > Background renderers may set dirty regions so they know what they'll need > to repaint though. (I could be wrong on all this, darin is the one who > knows best.) > I think I was overzealous saying that GIFs don't animate when in background > tabs. They're designed not to, but the actual signal they use is (among > other things) ScrollView::isOffscreen(), which looks like it's pretty much a > NOP for our port. So one thing you could try is seeing if you can implement > a Chromium version of platformIsOffscreen() and anything else that function > needs, and check whether that helps lower CPU (e.g. for animated images in > background tabs). Another way to approach this in general is to take a high-CPU site, put it in a background tab, then attach gdb to the process and break. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 5:53 AM, Joel Stanley wrote: > So we do this for GIFs. Can anyone tell me if background tabs > re-paint themselves? If not, I'll add it to the TODO. IIRC renderers don't actually paint until the browser tells them to. Background renderers may set dirty regions so they know what they'll need to repaint though. (I could be wrong on all this, darin is the one who knows best.) I think I was overzealous saying that GIFs don't animate when in background tabs. They're designed not to, but the actual signal they use is (among other things) ScrollView::isOffscreen(), which looks like it's pretty much a NOP for our port. So one thing you could try is seeing if you can implement a Chromium version of platformIsOffscreen() and anything else that function needs, and check whether that helps lower CPU (e.g. for animated images in background tabs). PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 00:53, Dan Kegel wrote: > It'd be nice if users didn't have to do that... > does HTML 5 specify any kind of low power idle state for applications? > Ideally when the screen blanks, we'd want all the apps to go > into some kind of low power state, wouldn't we? It would be great if Gmail (or similar) could ask Chrome if it's in the background, and do less work until it comes back into focus. Mmm and use Android style tickles to wake up when new email arrives... >> Perhaps we could run a powertop bot, that monitors an idle session >> with a few tabs opened to catch any regressions with timers. > > I like that idea a lot. Cool! I need inside help to make that happen, are you the person I can poke? I've spent today looking into collecting powertop numbers. The latest version of gnome-power-manager has a powertop-like tab, and it's scraping it's data from devicekit-power. Karmic has both of these, I thought Jaunty had devkit-power but looking again I might have been mistaken. So once we have a system that has devicekit-power, we can use a tool[1] from the source tree to dump stats: $ ./devkit-power -w Total wakeups per minute: 462 Wakeup sources: userspace:0 id:12, interrupts:216.0, cmdline:interrupt, details:i8042 userspace:0 id:4082, interrupts:91.0, cmdline:kernel-ipi, details:Rescheduling interrupts userspace:0 id:30, interrupts:64.5, cmdline:interrupt, details:PCI-MSI-edge iwlagn userspace:0 id:28, interrupts:43.0, cmdline:interrupt, details:PCI-MSI-edge i915 userspace:0 id:14, interrupts:15.0, cmdline:interrupt, details:ata_piix userspace:1 id:5971, interrupts:8.9, cmdline:/home/shenki/chrome/chrome, details:hrtimer_start_range_ns (hrtimer_wakeup) userspace:1 id:29472, interrupts:8.5, cmdline:/usr/lib/firefox-3.5/firefox-3.5, details:hrtimer_start_range_ns (hrtimer_wakeup) Next is collecting them in the same manner that other perf stats are collected... Joel [1] http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/tree/tools --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 3:09 PM, Joel Stanley wrote: > On Tue, Jul 14, 2009 at 03:09, Craig Schlenter > wrote: >> I've mentioned this to Joel off-list but in case anyone else is interested, >> I have code that runs background tabs at lower scheduling priorities >> on linux. > > Thanks. Are you able to post the newer version you mentioned? Attached. Haven't checked if it works with the latest tree. >> Tweaks to /etc/security/limits.conf are necessary to make it work though >> (to grant priority raising abilities). > > If we're just tweaking the priority level between 0 and 20 a normal > user will have no worries. It's only when we try to take it below 0 > that more capabilities are needed. > > $ renice +1 31404 > 31404: old priority 0, new priority 1 > > $ renice -1 31404 > renice: 31404: setpriority: Permission denied > > $ renice +3 31404 > 31404: old priority 1, new priority 3 > > $ renice +1 31404 > 31404: old priority 3, new priority 1 > > OTOH, renicing isn't really going to help my quest to end unnecessary > background work, it's just going to make sure the foreground gets more > CPU share. I was under the impression that lowering the priority was always allowed but taking it back to the original level was denied. Can you get it back to the original priority 0 without the fiddling in /etc/security/limits.conf I mentioned? Maybe your distribution already grants you extra scheduling permissions? I'm on fedora 9. ulimit -a may yield some clues ... I concur that it will probably only help foreground processes get more share of the cpu but perhaps in conjunction with something like cpu clock throttling, it might help the machine use less power and still have a usable browsing experience in the foreground tab. I haven't really studied any of the linux cpufreq stuff yet though... I'm not sure how often the browser pokes at the background tabs/renderers to see if they are active but maybe you could alter that code to wake up the renderer, wait a short while for the ping response and then stop the renderer again? --Craig --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- commit-5bf3a45 Description: Binary data
[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 03:09, Craig Schlenter wrote: > I've mentioned this to Joel off-list but in case anyone else is interested, > I have code that runs background tabs at lower scheduling priorities > on linux. Thanks. Are you able to post the newer version you mentioned? > Tweaks to /etc/security/limits.conf are necessary to make it work though > (to grant priority raising abilities). If we're just tweaking the priority level between 0 and 20 a normal user will have no worries. It's only when we try to take it below 0 that more capabilities are needed. $ renice +1 31404 31404: old priority 0, new priority 1 $ renice -1 31404 renice: 31404: setpriority: Permission denied $ renice +3 31404 31404: old priority 1, new priority 3 $ renice +1 31404 31404: old priority 3, new priority 1 OTOH, renicing isn't really going to help my quest to end unnecessary background work, it's just going to make sure the foreground gets more CPU share. Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Tue, Jul 14, 2009 at 01:52, Evan Martin wrote: >> I've used it to browse on real hardware; the Beagleboard, an OMAP3 >> based ARM board with 128MB of RAM. > > Wow, impressive. How much do you think multi-process hurts us? The full story is 128MB of RAM + 128MB of swap on a slow (class 4) SD card. Multi-process changes the game, at least wrt memory. Normally once you hit the memory ceiling the system is unresponsive until the OOM killer takes out something (on the OLPC XO this would often be X, losing the entire session). With Chrome, opening a 3rd tab results in the new renderer instantly crashing (if it's even starting?), leaving you restricted to two tabs but free to continue browsing in those two. So IMO, multi-process makes us fail in much nicer ways :) But we will hit that memory ceiling sooner due to the overheads of being multi-process. The ~500Mhz CPU is pegged when rendering, but the system goes near-idle once drawing has finished. Scrolling takes it back up to 100%. I haven't used it much, but will do more often going forward now that I can build using the tree. On the topic of the ARM build, it would be great if we could have a buildbot doing cross compiles. I filed a bug at http://crbug.com/16321, is there anything else I can do to follow that up? > One piece to look at is the code that calls SetProcessBackgrounded(), > which on Windows marks the process as one that can be paged out but on > Linux is not implemented. I don't know how it decides it's ok to do > that, but it'd be good logic to examine. I'll take a look. My email was kicked off after discovering the SystemMonitor class, which I understand is only used for switching on and off high-res timers on Windows. These both sound like good switches for enabling efficient behaviour. > I think it'd be pretty interesting to fully suspend background tabs, > but doing it safely is likely tricky. For example, imagine a page > that has Javascript that is driving a Flash plugin playing background > music. I wonder if it would be possible to detect that sound is coming from a tab. Perhaps it's not worth it, as the case of IM in the background tab will be really hard to detect in a generic fashion. The only reliable way the browser will discover that a tab is inactive is for the user to tell it. Right click -> "Pause this tab"? This would be a UI win over my current `pgrep firefox | xargs kill -STOP` :) >> Other things to look at would be timers that fire 'too often', and >> pausing animated content such as gifs and flash. > > Even for stuff like gifs that don't have audio, you could imagine a > page with a very long animated gif, where I might switch away from the > tab and expect it to be farther along when I come back. > > Here's an idea: when a page is in the background don't let it repaint. > That means when you switch to it you'll have to wait for it to > repaint, but maybe that's an ok tradeoff. (Maybe we do this already.) So we do this for GIFs. Can anyone tell me if background tabs re-paint themselves? If not, I'll add it to the TODO. > A final idea is simply looking at performance overall. > We haven't yet looked at even a profile and we very well could be > doing a lot of unnecessary work. > For example, I believe the renderer spams the browser repeatedly with > "set tooltip" messages as you move the mouse around. I think I saw a > bug filed suggesting we could have the renderer only send the message > if the tooltip changed. Maybe that's not enough work to waste much > battery, though. > This is more generic, but perhaps more realistic. This would be best discovered by looking at IPC traffic going past? Thanks for the reply, Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Mon, Jul 13, 2009 at 6:22 PM, Evan Martin wrote: [snip] > One piece to look at is the code that calls SetProcessBackgrounded(), > which on Windows marks the process as one that can be paged out but on > Linux is not implemented. I don't know how it decides it's ok to do > that, but it'd be good logic to examine. I've mentioned this to Joel off-list but in case anyone else is interested, I have code that runs background tabs at lower scheduling priorities on linux. Tweaks to /etc/security/limits.conf are necessary to make it work though (to grant priority raising abilities). --Craig --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Mon, Jul 13, 2009 at 10:05 AM, Scott Hess wrote: > On Mon, Jul 13, 2009 at 9:37 AM, Peter Kasting > wrote: > > For a common real-life example people want to work, imagine having > Pandora > > open in a background tab. People expect it to keep playing music. > > Is it using Flash to play the music? Yes, Pandora uses Flash. Note that even if you don't suspend the Flash process, you have to be careful since Flash may interact with script, and thus you (probably) can't safely suspend any renderers embedding Flash. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Mon, Jul 13, 2009 at 9:37 AM, Peter Kasting wrote: > On Mon, Jul 13, 2009 at 9:22 AM, Evan Martin wrote: >> I think it'd be pretty interesting to fully suspend background tabs, >> but doing it safely is likely tricky. For example, imagine a page >> that has Javascript that is driving a Flash plugin playing background >> music. > > For a common real-life example people want to work, imagine having Pandora > open in a background tab. People expect it to keep playing music. Is it using Flash to play the music? Presumably if your web page were thoroughly HTML5, the browser could arrange to only idle tabs which were thoroughly undetectable, so if it were playing music, the assumption would be that it shouldn't be idled. I think the real question is whether low-power is useful enough to be worth targeting. There needs to be enough benefit (the 8% reduction mentioned is probably the maximum), and it needs to be tractable. Maybe something like profiling which flags tabs that are using a lot of CPU. Plug-ins make this hard, of course, but there may be practical ways to work around that by attributing plug-in CPU time to the tab which caused it as possible, and tracking background plug-in threads separately. Perhaps the kind of thing that could be surfaced for an extension to hook into. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Mon, Jul 13, 2009 at 9:22 AM, Evan Martin wrote: > I think it'd be pretty interesting to fully suspend background tabs, > but doing it safely is likely tricky. For example, imagine a page > that has Javascript that is driving a Flash plugin playing background > music. For a common real-life example people want to work, imagine having Pandora open in a background tab. People expect it to keep playing music. > Other things to look at would be timers that fire 'too often', and > > pausing animated content such as gifs and flash. > > Even for stuff like gifs that don't have audio, you could imagine a > page with a very long animated gif, where I might switch away from the > tab and expect it to be farther along when I come back. In fact GIFs do not animate when they're not visible (i.e. in background tabs), they simply check how much time has elapsed since their last paint when they become visible again, and spin the GIF forward as necessary to simulate having been animating the whole time. (This code went in last fall.) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Mon, Jul 13, 2009 at 9:22 AM, Evan Martin wrote:
>> As we're multi process with Chrome we could instead suspend any
>> background renderers, plugin and extension processes without affecting
>> the foreground tabs.
>
> One piece to look at is the code that calls SetProcessBackgrounded(),
> which on Windows marks the process as one that can be paged out but on
> Linux is not implemented. I don't know how it decides it's ok to do
> that, but it'd be good logic to examine.
Sorry, bad tip. Try looking at
void BrowserRenderProcessHost::SetBackgrounded(bool backgrounded) {
instead.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Improving power usage
On Mon, Jul 13, 2009 at 8:19 AM, Joel Stanley wrote: > So far I've spent my 'summer' (it's winter here in Australia) on the > ARM port of Chromium. As of the recent v8 gyp changes, the tree can > build for ARM (and thumb, for a binary that's around ~25% smaller) and > I've used it to browse on real hardware; the Beagleboard, an OMAP3 > based ARM board with 128MB of RAM. Wow, impressive. How much do you think multi-process hurts us? > On my laptop I send SIGSTOP to Firefox when I'm not using it, to save > battery without losing state. This saves me 1 Watt when running Gmail > in Firefox 3, or around 8% of the system power draw on my Thinkpad > X300. > > As we're multi process with Chrome we could instead suspend any > background renderers, plugin and extension processes without affecting > the foreground tabs. One piece to look at is the code that calls SetProcessBackgrounded(), which on Windows marks the process as one that can be paged out but on Linux is not implemented. I don't know how it decides it's ok to do that, but it'd be good logic to examine. I think it'd be pretty interesting to fully suspend background tabs, but doing it safely is likely tricky. For example, imagine a page that has Javascript that is driving a Flash plugin playing background music. > Other things to look at would be timers that fire 'too often', and > pausing animated content such as gifs and flash. Even for stuff like gifs that don't have audio, you could imagine a page with a very long animated gif, where I might switch away from the tab and expect it to be farther along when I come back. Here's an idea: when a page is in the background don't let it repaint. That means when you switch to it you'll have to wait for it to repaint, but maybe that's an ok tradeoff. (Maybe we do this already.) > Wakeups are not too bad, but any savings will mean longer lasting batteries: > > 28.4% (187.4) firefox-3.5 : hrtimer_start_range_ns (hrtimer_wakeup) > 4.1% ( 26.9) chrome : hrtimer_start_range_ns (hrtimer_wakeup) > 2.3% ( 15.0) chrome : ep_poll (process_timeout) > > (Powertop output of Firefox 3 vs Chromium trunk, one tab running Gmail, on > Ubuntu Karmic) > > Perhaps we could run a powertop bot, that monitors an idle session > with a few tabs opened to catch any regressions with timers. A final idea is simply looking at performance overall. We haven't yet looked at even a profile and we very well could be doing a lot of unnecessary work. For example, I believe the renderer spams the browser repeatedly with "set tooltip" messages as you move the mouse around. I think I saw a bug filed suggesting we could have the renderer only send the message if the tooltip changed. Maybe that's not enough work to waste much battery, though. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
