Repository navigation
mobile: Add thread-placement policy hooks #46813
Description
Currently servo doesn't attempt to do anything in terms of informing the scheduler what threads are important.
That can lead to very suboptimal results on heterogeneous architectures (placing script on little cores in a big.little architecture is obviously not great for performance).
Probably a proper solution for this should allow the embedder to modify or even design the policy.
Setting thread affinity in servo itself might also be quirky, so that would be another reason to place it at the embedder level.
Reacted by Euclid Ye
Activity
yezhizhen commentedon Jul 28, 2026
Probably explains why my benchmark results for #45199 varies so much for different devices with same hardware config. (All my results are done on one device so it is consistent)
Narfinger commentedon Jul 28, 2026
I wonder what a good design for this would be. Perhaps we can just have a big struct that has a bunch of callbacks per thread type and give that to constellation.
jschwe commentedon Jul 28, 2026
The main thing I want to think about more is how embedder defined code can run reliably in cross process mode.
Currently this works since we fork-exec the same binary (in servoshell), so the embedder code is all there. But that's just an accident, and I want to think what we need to require. Perhaps the code should be in a shared library that can be dlopened?
perf: add initial threadboost mechanism (for ohos). (servo#46843)
perf: add initial threadboost mechanism (for ohos). (servo#46843)