Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3a7d28d2021a23bd6607feedb9407638fc14e88f
https://github.com/WebKit/WebKit/commit/3a7d28d2021a23bd6607feedb9407638fc14e88f
Author: Georges Basile Stavracas Neto <[email protected]>
Date: 2025-12-16 (Tue, 16 Dec 2025)
Changed paths:
M Source/WTF/wtf/glib/RunLoopGLib.cpp
M Source/cmake/OptionsCommon.cmake
Log Message:
-----------
[GLIB] Use timerfd to improve timer resolution
https://bugs.webkit.org/show_bug.cgi?id=303921
Reviewed by Adrian Perez de Castro.
WebKit timers in GLib have a big lateness range (up or more than 1ms).
We can have better timers by using timerfd in a few selected places.
Make RunLoopSource use a timerfd when starting RunLoop::TimerBase
instances. The timerfd itself is created as late as possible, and
only when the timer has an interval set. That's because some timers
are created but rarely started, so we can save a few fds by delaying
the timerfd creation.
Some measurements. Before this patch:
```
WebPageProxy::GeneratePageLoadTimingTimer lateness: 59µs
MainThreadSharedTimer::timer lateness: 613µs
MainThreadSharedTimer::timer lateness: 92µs
MainThreadSharedTimer::timer lateness: 500µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 2µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 867µs
MainThreadSharedTimer::timer lateness: 605µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 527µs
MainThreadSharedTimer::timer lateness: 194µs
MainThreadSharedTimer::timer lateness: 487µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 612µs
MainThreadSharedTimer::timer lateness: 687µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 423µs
MainThreadSharedTimer::timer lateness: 305µs
MainThreadSharedTimer::timer lateness: 161µs
MainThreadSharedTimer::timer lateness: 49µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 41µs
MainThreadSharedTimer::timer lateness: 431µs
MainThreadSharedTimer::timer lateness: 883µs
JSRunLoopTimer::Manager::PerVMData::Timer lateness: 738µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 496µs
JSRunLoopTimer::Manager::PerVMData::Timer lateness: 255µs
JSRunLoopTimer::Manager::PerVMData::Timer lateness: 124µs
```
After this patch:
```
WebPageProxy::GeneratePageLoadTimingTimer lateness: 15µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 10µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 6µs
MainThreadSharedTimer::timer lateness: 9µs
MainThreadSharedTimer::timer lateness: 10µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 9µs
MainThreadSharedTimer::timer lateness: 7µs
MainThreadSharedTimer::timer lateness: 416µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 10µs
MainThreadSharedTimer::timer lateness: 10µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 12µs
MainThreadSharedTimer::timer lateness: 8µs
MainThreadSharedTimer::timer lateness: 7µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 10µs
MainThreadSharedTimer::timer lateness: 19µs
MainThreadSharedTimer::timer lateness: 20µs
JSRunLoopTimer::Manager::PerVMData::Timer lateness: 35µs
BitmapTexturePool::ReleaseUnusedTexturesTimer lateness: 15µs
JSRunLoopTimer::Manager::PerVMData::Timer lateness: 24µs
JSRunLoopTimer::Manager::PerVMData::Timer lateness: 12µs
PrivateClickMeasurementManager::FirePendingAttributionRequestsTimer lateness:
24µs
HysteresisActivity::Timer lateness: 14µs
```
It doesn't seem to affect MotionMark results.
* Source/WTF/wtf/glib/RunLoopGLib.cpp:
(WTF::RunLoop::RunLoop):
(WTF::RunLoop::TimerBase::TimerBase):
(WTF::RunLoop::TimerBase::start):
* Source/cmake/OptionsCommon.cmake:
Canonical link: https://commits.webkit.org/304553@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
