2007547 - Consider moving URLPreloader AutoBeginReading work to the main thread

Status: ASSIGNED

(Core :: XPConnect, task)

Description

[Markus Stange [:mstange]]

Here's a profile from an A55 running the newssite-applink task in CI: https://share.firefox.dev/4rpEghN

In this particular run, the main thread was blocking in the Wait() call in ~AutoBeginReading at the end of ScriptPreloader::InitCache(), waiting for a background thread to finish a rename syscall.

I think the work we're blocking on here might as well happen on the main thread. Yes, it's IO (reading and renaming files), but it's happening interleaved with other IO for the ScriptPreloader cache that's already happening on the main thread. Also, from a scheduling perspective, "busy threads run faster" and get put on bigger cores. In general we've learned that making the main thread block on something that happens on another thread is usually a bad idea because the scheduling priorities often don't propagate the way you'd want them to.

Comment 1

[Markus Stange [:mstange]]

Attachment: Bug 2007547 - Move URLPreloader reading to the main thread. r=tcampbell

Before: https://share.firefox.dev/4rpEghN

The main thread blocks on reader initialization very soon after kicking off the read.
There's not much parallelism happening. So it's better to just do the reading on the
main thread directly. This way we're less likely to get into a situation where a
big core is waiting for a slow core.