This could help us find scheduling regressions.

Bill said he'd do this as part of his incremental GC stuff, as he's already computing things like what % of the time is in the GC.

And actually, that undersells what he is already computing a bit. Here's his comment about what he is computing: /* * MMU (minimum mutator utilization) is a measure of how much garbage collection * is affecting the responsiveness of the system. MMU measurements are given * with respect to a certain window size. If we report MMU(50ms) = 80%, then * that means that, for any 50ms window of time, at least 80% of the window is * devoted to the mutator. In other words, the GC is running for at most 20% of * the window, or 10ms. The GC can run multiple slices during the 50ms window * as long as the total time it spends is at most 10ms. */ It looks like he is currently computing MMU(20ms) and MMU(50ms).

Here's a patch on top of the incremental GC stuff. I only added MMU(50ms). Our MMU for smaller window sizes is pretty bad even in testing, so it's probably not worth reporting right now.

Comment on attachment 591675 [details] [diff] [review] patch Review of attachment 591675 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!

This was r+ 3 weeks ago. Who can land these new probes?

The patch is based on incremental GC, so it can't land yet. However, I realize that besides the MMU measurement, it would be nice just to know how many seconds ago the last GC was. So maybe I'll do a separate patch for that. It could land right away.

Looks like this landed with incremental GC, so I'm marking as fixed.

The target milestone isn't set. Did this land in time for 12 or 13?