Enable timer coalescing outside of Nightly
Categories
(Core :: XPCOM, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox116 | --- | fixed |
People
(Reporter: jlink, Assigned: jlink)
References
Details
Attachments
(1 file)
https://bugzilla.mozilla.org/show_bug.cgi?id=1783405 introduced, and https://bugzilla.mozilla.org/show_bug.cgi?id=1830139 increased, a threshold that allows TimerThread to intentionally fire some timers a little later than requested, however this value is set zero, effectively disabling that functionality, outside of nightly builds.
This has been enabled in Nightly without any problems for quite some time so let's get it enabled everywhere.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Comment 2•2 years ago
|
||
florian, have you seen any changes in the power usage numbers or telemetry or anything, on Nightly?
Assignee | ||
Comment 3•2 years ago
•
|
||
Olli asked for some data on the impact of this change in the code review so I am adding them here.
If you look at the glam metrics (switch to "Histogram Data" first) you can see an increase in the rate at which we fire 4, 3 and 2 timers per-wake-up, starting with the 2023-04-12:09 build when the first timer coalescing landed. It's about one percentage point increase on each but it is consistent and persistent. By my calculations we went from about 0.50 timers/wake-up to 0.55 as a result of these changes.
Another interesting thing that I noted while scrolling through the data is that, on some of the builds with fewer data points such as 2023-05-11:19, 2023-05-22:13, 2023-05-25:21 and 2023-05-29:8, there are even now instances in which we were able to coalesce many more timers together (probably long-running timers) which is pretty cool. I imagine that this is happening in the other builds too, but the rates are getting rounded down to 0%.
Assignee | ||
Updated•2 years ago
|
Comment 4•2 years ago
|
||
(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #2)
florian, have you seen any changes in the power usage numbers or telemetry or anything, on Nightly?
When looking at the telemetry for wake-ups by thread name, the Timer thread represents between 6 and 8% of all the thread wake-ups. There's enough noise that it's hard to see exactly if/when there is a change, but if I assume I should look at the 2023-04-12 date that Justin gave in comment 3, it looks like I have a lot more days where the percentage is 6 point something after that date than before. There might be an improvement of about 0.5% of the total wake-ups, but it's hard to say as it's within the noise level.
If I look only at thread wake-ups in background content processes, the timer thread represents between 18 and 22% of wake-ups before April 12 (about 20% on most days), and between 15 and 20% after April 12 (with most days between 17 and 18%). The data is noisy there too, but I think there's definitely an improvement.
I will also note that Nightly is not the best channel to see the impact of bundling long timers, as we have many short 128ms timers caused by BHR on the Nightly channel.
Comment 5•2 years ago
|
||
https://glam.telemetry.mozilla.org/fog/probe/timer_thread_timers_fired_per_wakeup/explore?aggType=avg¤tPage=12&ping_type=*&timeHorizon=QUARTER&visiblePercentiles=%5B99.9%2C99%5D is perhaps a bit easier visually.
Comment 7•2 years ago
|
||
bugherder |
Description
•