Linux fedora core8 - firefox 2.0.0.10 steps to reproduce: start the linux tool "powertop" start firefox powertop shows zero or few wake ups login to gmail or visit other ajax sites. powertop shows firefox will jump to the top of the list of total wakeups on the system somewhere around 50% or more depending on other apps that might be running. might see something like this reported by powertop - 41% total wake ups. ~ 160 wake ups per second firefox-bin : schedule_time out(process timeout) need to test animated gifs, flash with flash at youtube also see reports of 9% tl - 48 wakeups per second - firefox-bin : futex_wait (hrtimer_wakeup) these numbers remain consitantly high even when the browser windows are minimized.

the result of these wake up calls is that power consumption on a laptop or other power constrained device will be higher than might be expected. I wonder if there is a way that we might put some controls around areas that are making the web content driven wake up calls to reduce or stop them in certain situations like when browser windows are minimized. also need to test to see if this is still a problem on the trunk

this article seems to indicate there is at least one patch around to help out with firefox power consumption http://www.linux.com/articles/62091 I guess more research is needed to see if it addresses this specific problem.

(In reply to comment #2) > this article seems to indicate there is at least one patch around to help out > with firefox power consumption http://www.linux.com/articles/62091 That's bug 380558, which is already in Firefox 2.0.0.5, and also on the trunk. > > I guess more research is needed to see if it addresses this specific problem. >

This is still valid :(

might have some impact on battery life for mobile devices as well.

Still seeing excessive wakeups in Seamonkey, even with no browser windows open (and just the MailNews window open). strace on the process shows a continuous stream of wakeups on a particular pipe. gdb backtrace shows this is a poll inside libglib. It seems like there's an awful lot of sockets and pipes open for an idle process. (Switching into offline mode doesn't reduce the activity either.)

gdb backtrace: (gdb) bt #0 0x00007fa9a0390236 in poll () from /lib/libc.so.6 #1 0x00007fa9a15723c8 in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007fa9a15726eb in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007fa9961dacc5 in nsBaseAppShell::DoProcessNextNativeEvent () from /home/software/mozobc/mozilla/dist/bin/components/libwidget_gtk2.so #4 0x00007fa9961dae13 in nsBaseAppShell::OnProcessNextEvent () from /home/software/mozobc/mozilla/dist/bin/components/libwidget_gtk2.so #5 0x00007fa9a43ff53d in nsThread::ProcessNextEvent () from /home/software/mozobc/mozilla/dist/bin/libxpcom_core.so #6 0x00007fa9a43d47be in NS_ProcessNextEvent_P () from /home/software/mozobc/mozilla/dist/bin/libxpcom_core.so #7 0x00007fa9961daf35 in nsBaseAppShell::Run () from /home/software/mozobc/mozilla/dist/bin/components/libwidget_gtk2.so #8 0x00007fa99547d889 in nsAppStartup::Run () from /home/software/mozobc/mozilla/dist/bin/components/libtoolkitcomps.so #9 0x00007fa9a4869474 in XRE_main () from /home/software/mozobc/mozilla/dist/bin/libxul.so #10 0x0000000000401b12 in main () (gdb) quit

What are all these unix domain sockets, fifos, and pipes?

cc'ing taras since he's looking at many things perf related these days.

This is rather old, a lot of work has been done in the last 2 years on reducing wakeups. Is this still an issue?

sounds like there might be a difference in wake up activity on desktop and mobile. it might be good to have a map of those differences, and test cases that demonstrate common use cases where wake ups (and power consumption) get exercised and evaluated.

We did a lot of work to reduce the amount of wakeups in general. However, we have, AFAIK, no specific code to prevent wakeups when minimized. In other words, testing when minimized adds nothing new. But, we might have unneeded wakeups in general. We should investigate that. There are patches that will print out every single wakeup, that can quickly narrow this down. I'll run some tests. Note that we expect more wakeups on desktop than on mobile, for example due to the idleservice doing polling (which we do not do on mobile, because Android for example can't do polling). Not that we shouldn't fix this stuff - we should. Note also that we do throttle timers in background tabs with bz's recent patch. There were some issues with it but overall it looks like a big win for power. In theory we can do the same when minimized - the main tab is then 'effectively' a background tab. I'm not sure if this would work well though.

Did some browsing now with a timer-profiling build. As expected, desktop has more wakeups than mobile. For example, the url classifier (google safe browsing) wakes up now and then (we don't use it on mobile). Also, mobile websites have fewer animations, JS, etc. I don't see anything that looks clearly wrong. So, the issue is, what can we do to websites that do a lot of stuff. As mentioned above, we do throttle such things in background tabs. We can consider doing that to all tabs when minimized. However, this can definitely lead to regressions, as websites will behave differently. I don't feel I can predict the risk involved here. Side issue, would be interesting to compare the amount of wakeups firefox has, when minimized, to other browsers.

bz, in comment 12 and comment 13 the idea came up to throttle timers in the foreground tab when minimized, similarly to your recent patch that throttles them in background tabs (that is, treat the foreground tab as being in the background, when we are minimized). Does that make sense?

I think we should treat all tabs in minimized windows as background tabs, yes. I thought we even had bugs on that....

Yes, we have bug 648045.