Discussed with Stephen Kyle (ARM) @ Blink On 9.

The problem is we can't indicate this temporary dependency of the main thread to the OS.

FWIU, the governor doesn't take thread priority into account but rather some threads can have a multiplier which influences a thread's workload's count towards the quota that ends up heuristically labeling a thread as "must run on BIG"

In Chrome, Android/CrOS use cgroups to put threads explicitly labeled as ThreadPriority::DISPLAY into a special group that boosts its workload's contribution towards "doing important work / must run on BIG".

But, even if we used priority inheritance mutexes to indicate the main thread being blocked on a worker thread. It might raise the priority of the thread (and it could also put it in the group of "workload on this thread should count more") but it wouldn't immediately promote it to BIG even though the blocked main thread is set to run on BIG... (arguably a kernel issue..?).

We also don't wait to blindly label SchedulerWorkers as ThreadPriority::DISPLAY to be in the aforementioned cgroup as not all workload is USER_BLOCKING on a worker thread and it would be wrong to hint the kernel that this thread should always run on BIG...

The "solution" would be for TaskScheduler to have a whole separate set of threads for USER_BLOCKING work (and of course only schedule enough threads at once for the machine's capacity)...

Requiring 2X the number of threads is sad. I still think the best way to solve this would be for the kernel to expose a way to tell it a thread depends on another from user mode...

But as Stephen and I discussed we also haven't proven these priority inversions are a real problem in the wild (i.e. regularly skip frames because of it). The traces I provided had the inversion resolve within ~4ms.

@V8 GC: We should add a UMA metric of how long the main thread waits for workers in the wild after completing its chunk of the workload.