1366353 - Consider raising the priority of the compositor thread

Status: RESOLVED WONTFIX

(Core :: Graphics, enhancement, P3)

Description

[Markus Stange [:mstange]]

Jeff and Ehsan were looking at a profile that was taken on the reference machine, where the GPU process wasn't doing anything for 64ms (not even running the sampler thread), while the main process was waiting for it, and during that time an idle content process was actively running the sampler thread.

In this case, the GPU process certainly had more important work to do than the idle content process.

We should experiment with increasing the priority of the GPU process, or even just the compositor thread in the GPU process if we can.

Comment 1

[(no longer active)]

For the profile in question see bug 1366358 comment 1.

Comment 2

[(no longer active)]

I think it's simpler and better (and less drastic) to increase the priority of the compositor thread to begin with here.

Comment 3

[(no longer active)]

I'm not actively working on this.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Bug 980027 added some thread prioritization gunk for the compositor on b2g. I'm not sure whether or not any of that is re-usable, but it's probably worth looking at, regardless.

Comment 5

[Gabriele Svelto [:gsvelto]]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #4)
> Bug 980027 added some thread prioritization gunk for the compositor on b2g.
> I'm not sure whether or not any of that is re-usable, but it's probably
> worth looking at, regardless.

Unfortunately the only thing that made it possible was the fact that b2g main process run as root and thus could arbitrarily change thread nice values & assign threads to control groups.

Comment 6

[Ryan Hunt [:rhunt] (on leave until early May)]

I'm removing that dead code in bug 1455408.

Looking at the profile, the blocking sync message is an APZ input message. It's possible this has gotten better since bug 1441324 moved this work from the compositor thread to the gpu process main thread. If it hasn't it might make sense to raise the priority of that thread slightly.

I'm sure this has been talked about locally, but just to note it here, one potential problem with raising the priority of the compositor thread is that it may lead to worse performance in some cases.

The example mstange gave me was when we're animating a throbber during page load. In this case we'd like the main thread to continue making progress, and giving the compositor higher priority could starve it.

It's possible we could dynamically change priorities for certain cases, but it seems like this is something that would need good measuring.

Comment 7

[Markus Stange [:mstange]]

Jeff, what do you think we should do here? I'm almost inclined to wontfix.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

I'm fine with WONTFIXing. We've already run into situations where the compositor is stealing cpu from other processes and causing slower load times. With WebRender we're doing even more cpu work in the gpu process so it's even more dangerous to raise the priority. More generally, we should have the strategy of lowering the priority of threads that we don't need response from soon instead of raising the priority of important ones. We also plan on investigating job scheduling more in webrender-next so it probably makes sense to deal with this then.