314101 2026-05-05 09:38:01 -0700 Rework ParkingLot spinloop to reduce scheduler thrashing 2026-05-11 20:21:25 -0700 1 1 1 Unclassified WebKit New Bugs WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 314267 1 marcus_plutowski webkit-unassigned commit-queue webkit-bug-importer oldest_to_newest 2207696 0 marcus_plutowski 2026-05-05 09:38:01 -0700 rdar://176237718 After failing to acquire a contended lock, a thread will optimistically spin for a little while before parking itself on the ParkingLot. This is beneficial to performance because very often the lock will be freed before the waiting thread needs to park. However, at present this loop calls sched_yield 40 times in a row. This causes two problems: 1. It reduces the “handoff quality” of the lock, as any thread acquiring the lock is ~guaranteed to resume execution with a depressed priority 2. It causes churn in the scheduler, especially when a large number of threads are all attempting to yield at once Experimentally, replacing the sched_yield with an equal time spinning on an appropriate nop has broad benefits across a number of platforms, but especially for A-series chips. Any test with significant GC activity benefits, as well as tests with light contention (where threads mostly don’t make it all the way through the parking loop). However, a small number of benchmarks — particularly JS3’s `bomb-workers` — are heavily contended enough that a large number of attempts at acquiring locks will park regardless of time-to-park, meaning the entire duration of the spinloop is executed on-core. In this scenario, sched_yield has the salubrious effect of reducing wasteage by allowing the scheduler to schedule this work on e.g. an e-core, reducing the impact. Entirely removing the sched_yield leads to upwards of a 40% regression on that subtest in particular, wiping out the benefits. The simple approach is to optimistically assume that, of those lock-acquisitions which *do* succeed in acquiring the lock during the spinloop period, most will acquire it early on. As such, we can avoid calling sched_yield until some number of iterations have passed (again, replacing it with a suitable nop-loop). Thereafter, the loop only needs to call sched_yield once every few iterations, since the priority-depression lasts for some time — and again, optimistically, we want to decrease the depression-duration that will be left if the thread does succeed in acquiring the core before the next sched_yield call. 2207703 1 marcus_plutowski 2026-05-05 09:52:49 -0700 Pull request: https://github.com/WebKit/WebKit/pull/64278 2208197 2 ews-feeder 2026-05-06 11:04:12 -0700 Committed 312720@main (697f0265b8f6): <https://commits.webkit.org/312720@main> Reviewed commits have been landed. Closing PR #64278 and removing active labels. 2208386 3 commit-queue 2026-05-06 17:52:26 -0700 Re-opened since this is blocked by bug 314267 2208633 4 marcus_plutowski 2026-05-07 10:36:17 -0700 Pull request: https://github.com/WebKit/WebKit/pull/64477 2209966 5 ews-feeder 2026-05-11 20:21:23 -0700 Committed 313051@main (d17da45094f8): <https://commits.webkit.org/313051@main> Reviewed commits have been landed. Closing PR #64477 and removing active labels.