1380144 - Collect hang information from the compositor process

Status: RESOLVED DUPLICATE of bug 1380081

(Toolkit :: Telemetry, enhancement)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

In Firefox 53 we released the "Quantum Compositor," aka compositor process. Unfortunately we missed an important detail, which is that hang reports can only be collected in content and parent processes. As a result when the GPU process is enabled we're effectively losing hang information about the compositor. I'm worried this could impact our knowledge of more serious jank.

We do have a timeout set for synchronous IPC, but paints are asynchronous, so it's possible that stuff just hangs and we don't know.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

Chris, I don't know if this is something we should flag for Flow or some other project?  Seems somewhat scary not having the hang info.

Comment 2

[Chris Peterson [:cpeterson]]

Jean or Naveed, who can fix the hang reporter to include information about the compositor process?

Comment 3

[Jean Gong :jgong]

Michael, Is there anything you can do in the short term to fix this?

Comment 4

[Nika Layzell [:nika] (ni? for response)]

(In reply to Jean Gong from comment #3)
> Michael, Is there anything you can do in the short term to fix this?

This should be being fixed in bug 1380081. I tried to make sure that the new data collection mechanism which I added in that bug supports collecting data from the GPU process.

Comment 5

[Georg Fritzsche [:gfritzsche]]

Did bug 1380081 fix this? Should we dupe this bug against it?

If not, what is a good component to move this bug to?

Comment 6

[Nika Layzell [:nika] (ni? for response)]

(In reply to Georg Fritzsche [:gfritzsche] from comment #5)
> Did bug 1380081 fix this? Should we dupe this bug against it?
> 
> If not, what is a good component to move this bug to?

Yes, we are collecting compositor hangs and you can see them on hangs.html: https://squarewave.github.io/?category=all&durationSpec=128_512&payloadID=d2647388aed04aad9c4b3ddd51845c6b&thread=2

It looks like we have a lot of `(other)` frames right now on that thread/process. An `(other)` frame I believe is created as an aggregation of other frames which are < 0.001% of the overall hang time of its parent (ni? dthayer to correct me if I got the number wrong).

Comment 7

[Alex Thayer [:alexical] (she/her)]

It's currently set at 1%. This tends to work all right for other threads / processes, but we may need to use a different value for the compositor process. I'll look into what these look like without the "other" globbing.

Comment 8

[Alex Thayer [:alexical] (she/her)]

(Turns our there was a bug in the pruning logic. The corrected payload is now visible: https://squarewave.github.io/?category=all&durationSpec=2048_65536&payloadID=170dd9c8944349a893e8026b93141d65&thread=3)