Closed
Bug 1366353
Opened 8 years ago
Closed 6 years ago
Consider raising the priority of the compositor thread
Categories
(Core :: Graphics, enhancement, P3)
Core
Graphics
Tracking
()
RESOLVED
WONTFIX
Performance Impact | low |
People
(Reporter: mstange, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf:responsiveness, Whiteboard: [gfx-noted])
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•8 years ago
|
||
For the profile in question see bug 1366358 comment 1.
Comment 2•8 years ago
|
||
I think it's simpler and better (and less drastic) to increase the priority of the compositor thread to begin with here.
Summary: Consider raising the priority of the GPU process → Consider raising the priority of the compositor thread
Updated•8 years ago
|
Assignee: nobody → ehsan
Updated•7 years ago
|
Priority: -- → P3
Whiteboard: [gfx-noted]
Updated•7 years ago
|
Whiteboard: [gfx-noted] → [gfx-noted][qf]
Comment 4•7 years ago
|
||
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•7 years ago
|
||
(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.
Updated•7 years ago
|
Whiteboard: [gfx-noted][qf] → [gfx-noted][qf:f63][qf:p1]
Comment 6•7 years ago
|
||
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.
Updated•6 years ago
|
Whiteboard: [gfx-noted][qf:f63][qf:p1] → [gfx-noted][qf:f64][qf:p1]
Updated•6 years ago
|
Whiteboard: [gfx-noted][qf:f64][qf:p1] → [gfx-noted][qf:p1:f64]
Updated•6 years ago
|
Whiteboard: [gfx-noted][qf:p1:f64] → [gfx-noted][qf:p1:f67]
Reporter | ||
Comment 7•6 years ago
|
||
Jeff, what do you think we should do here? I'm almost inclined to wontfix.
Flags: needinfo?(jmuizelaar)
Whiteboard: [gfx-noted][qf:p1:f67] → [gfx-noted][qf:p3:responsiveness]
Comment 8•6 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jmuizelaar)
Resolution: --- → WONTFIX
Updated•3 years ago
|
Performance Impact: --- → P3
Keywords: perf:responsiveness
Whiteboard: [gfx-noted][qf:p3:responsiveness] → [gfx-noted]
You need to log in
before you can comment on or make changes to this bug.
Description
•