Content processes can request "idle time" from the parent process which will manage how many content process can run idle time tasks (like GC slices). It might be helpful to add makers to the gecko profiler for idle time allocation and release. They won't represent any activity necessarily, but to see when requests are made & granted might be helpful in profiles like Bug 1772806

(In reply to Paul Bone [:pbone] from comment #0)

Content processes can request "idle time" from the parent process which will manage how many content process can run idle time tasks (like GC slices). It might be helpful to add makers to the gecko profiler for idle time allocation and release. They won't represent any activity necessarily, but to see when requests are made & granted might be helpful in profiles like Bug 1772806

Can you describe a bit more what you have in mind? (feel free to ignore this request if you have a patch in progress and can share an example profile; that's better than an explanation)

When looking at the profile from bug 1772806 (https://share.firefox.dev/3Q8OzEr), I already see some information in the IPC markers:
IPCOut — PIdleScheduler::Msg_RequestIdleTime — sent to 44184
IPCIn — PIdleScheduler::Msg_IdleTime — received from 44184
IPCOut — PIdleScheduler::Msg_IdleTimeUsed — sent to 44184

I'm not sure what's missing. Or maybe no information is missing, but just by using more explicit markers, we would enable more people to notice that this is happening.

(In reply to Florian Quèze [:florian] from comment #1)

Can you describe a bit more what you have in mind? (feel free to ignore this request if you have a patch in progress and can share an example profile; that's better than an explanation)

When looking at the profile from bug 1772806 (https://share.firefox.dev/3Q8OzEr), I already see some information in the IPC markers:
IPCOut — PIdleScheduler::Msg_RequestIdleTime — sent to 44184
IPCIn — PIdleScheduler::Msg_IdleTime — received from 44184
IPCOut — PIdleScheduler::Msg_IdleTimeUsed — sent to 44184

I'm not sure what's missing. Or maybe no information is missing, but just by using more explicit markers, we would enable more people to notice that this is happening.

A bit of both. I'd like to make it more explicit that this is idle time, even though people who know those IPC messages can infer it. But also to include the duration of the idle time that is granted and how much is actually used. Then we'll be able to see very quickly on the time scale which of the events that are supposed to be within the idle time ARE actually within it, whether they overrun their time or not. (GC markers already have a field about this but something a little clearer could be interesting). But when a task finishes before the end of the idle time, like these really short GC slices, we'll see how much time is "unused". Not using time is fine, great your PC is faster. But if we then request idle time again latter like in this profile but don't use it all up it makes it clearer that yeilding then waking-up again is wasteful