Mobile/Powersaving/Wakeups: Difference between revisions
< Mobile | Powersaving
Jump to navigation
Jump to search
| (6 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
'Wakeups' are instances where a thread enters activity. Each such wakeup stops the CPU from sleeping. Several short wakeups are much worse than a single long wakeup, because each wakeup will prevent sleeping for a short time afterwards, and sleeping can save a lot of power (see [http://www.lesswatts.org/projects/powertop/ powertop docs]). So avoiding wakeups is important, and if they are unavoidable then 'clumping' them together is preferable to scattering them at semi-random times. | 'Wakeups' are instances where a thread enters activity. Each such wakeup stops the CPU from sleeping. Several short wakeups are much worse than a single long wakeup, because each wakeup will prevent sleeping for a short time afterwards, and sleeping can save a lot of power (see [http://www.lesswatts.org/projects/powertop/ powertop docs]). So avoiding wakeups is important, and if they are unavoidable then 'clumping' them together is preferable to scattering them at semi-random times. | ||
== | == Wakeups of Note == | ||
* ./toolkit/components/places/src/nsPlacesDBFlush.js:361 - {{bug|518804}} - happens in pairs with nsDOMStorageDBWrapper.cpp:103 (load our addons page from the link, then go to a quiet page (e.g. bugzilla) and wait.) | |||
* ./toolkit/components/places/src/nsPlacesExpiration.js:926 | |||
* ./startupcache/StartupCache.cpp:194 - saw once in the log, perhaps by chance | |||
* | Old data, uncertain: | ||
* | |||
* xpcom/ds/nsExpirationTracker.h:321 | |||
* xpcom/ds/nsRecyclingAllocator.cpp:235 (hundreds of seconds?) | |||
* xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:101 - likely some JS callbacks (~1/5 seconds) | * xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:101 - likely some JS callbacks (~1/5 seconds) | ||
* The TileManager code sets and attribute each time we paint, which causes the Refresh Driver to spring into action, and stay active for a few frames at 50Hz. As a result on pages with enough animations - even slow ones - the Refresh Driver timer constantly or almost constantly runs at 50Hz. This effectively nullifies the benefits of timer grouping/clumping, and ironically exactly in the case where that would have helped (lots of animations). But, the TileManager will be replaced by new Layers code, so hopefully this will be a thing of the past. | * The TileManager code sets and attribute each time we paint, which causes the Refresh Driver to spring into action, and stay active for a few frames at 50Hz. As a result on pages with enough animations - even slow ones - the Refresh Driver timer constantly or almost constantly runs at 50Hz. This effectively nullifies the benefits of timer grouping/clumping, and ironically exactly in the case where that would have helped (lots of animations). But, the TileManager will be replaced by new Layers code, so hopefully this will be a thing of the past. | ||
| Line 18: | Line 20: | ||
* SMIL SVG animation runs at a 20ms (50fps) timer, no matter what the animation | * SMIL SVG animation runs at a 20ms (50fps) timer, no matter what the animation | ||
* nsHttpConnectionMgr::OnMsgPruneDeadConnections (http keepalive stuff) | * nsHttpConnectionMgr::OnMsgPruneDeadConnections (http keepalive stuff) | ||
== Things to Investigate == | |||
* SetWaitableTimerEx in Windows 7 might help the OS group Gecko's timers with other timers running. Do other OSes have similar things? | |||
== Debugging/Finding Wakeups == | == Debugging/Finding Wakeups == | ||
[[Mobile/Powersaving/Wakeups/Debugging]] | [[Mobile/Powersaving/Wakeups/Debugging]] | ||
Latest revision as of 21:54, 3 December 2010
Overview
'Wakeups' are instances where a thread enters activity. Each such wakeup stops the CPU from sleeping. Several short wakeups are much worse than a single long wakeup, because each wakeup will prevent sleeping for a short time afterwards, and sleeping can save a lot of power (see powertop docs). So avoiding wakeups is important, and if they are unavoidable then 'clumping' them together is preferable to scattering them at semi-random times.
Wakeups of Note
- ./toolkit/components/places/src/nsPlacesDBFlush.js:361 - bug 518804 - happens in pairs with nsDOMStorageDBWrapper.cpp:103 (load our addons page from the link, then go to a quiet page (e.g. bugzilla) and wait.)
- ./toolkit/components/places/src/nsPlacesExpiration.js:926
- ./startupcache/StartupCache.cpp:194 - saw once in the log, perhaps by chance
Old data, uncertain:
- xpcom/ds/nsExpirationTracker.h:321
- xpcom/ds/nsRecyclingAllocator.cpp:235 (hundreds of seconds?)
- xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:101 - likely some JS callbacks (~1/5 seconds)
- The TileManager code sets and attribute each time we paint, which causes the Refresh Driver to spring into action, and stay active for a few frames at 50Hz. As a result on pages with enough animations - even slow ones - the Refresh Driver timer constantly or almost constantly runs at 50Hz. This effectively nullifies the benefits of timer grouping/clumping, and ironically exactly in the case where that would have helped (lots of animations). But, the TileManager will be replaced by new Layers code, so hopefully this will be a thing of the past.
Other wakeups to investigate:
- SMIL SVG animation runs at a 20ms (50fps) timer, no matter what the animation
- nsHttpConnectionMgr::OnMsgPruneDeadConnections (http keepalive stuff)
Things to Investigate
- SetWaitableTimerEx in Windows 7 might help the OS group Gecko's timers with other timers running. Do other OSes have similar things?