mthiesse@chromium.org lizeb@chromium.org The number of file descriptors in the watch list for the epoll message pump. Sampled periodically every minute for each thread with an epoll message pump. fionav@google.com clank-performance-team@google.com The time it takes to acquire a contended {LockType} on the {ThreadGroup} thread pool in the {ProcessName} process. This is recorded with probability 1/1000 when acquisition of the lock is likely to cause the thread to wait in the kernel. Note: The metric is reported for only clients with high-resolution clocks (a subset of Windows clients won't report it, see the Windows.HasHighResolutionTimeTicks histogram). anandrv@google.com clank-performance-team@google.com The time it takes to acquire a contended {LockType} on {ThreadName}. This is recorded with probability 1/1000 when acquisitiion of the lock is likely to cause the thread to wait in the kernel. Note: The metric is reported for only clients with high-resolution clocks (a subset of Windows clients won't report it, see the Windows.HasHighResolutionTimeTicks histogram). kawasin@google.com joelaf@google.com Records whether or not a pid is reused between the time a SetProcessState DBus request is dispatched and when the request's result is processed. Pid reuse can race with the DBus request to result in the requested scheduler settings being applied to the wrong process, although this metric cannot differentiate between winning and losing that race. This is emitted every time a new Chrome process is created or changes background state. kawasin@google.com joelaf@google.com Records whether or not a pid is reused between the time a SetThreadState DBus request is dispatched and when the request's result is processed. Pid reuse can race with the DBus request to result in the requested scheduler settings being applied to the wrong thread, although this metric cannot differentiate between winning and losing that race. This is emitted every time Chrome creates a thread or changes a thread type. kawasin@google.com joelaf@google.com Records whether ResourcedClient::WaitForServiceToBeAvailable() succeeds or not. It fails only when ObjectProxy::ConnectToNameOwnerChangedSignal() fails which we expect to fail very rarely. This is emitted every time the callback of ResourcedClient::WaitForServiceToBeAvailable() runs. kawasin@google.com joelaf@google.com Records amount of time it takes to execute SetProcessState DBus request on ChromeOS. This is emitted every time a new Chrome process is created or changes background state. All ChromeOS clients have high-resolution timers. kawasin@google.com joelaf@google.com Records amount of time it takes to execute SetThreadState DBus request on ChromeOS. This is emitted every time Chrome creates a thread or changes a thread type. All ChromeOS clients have high-resolution timers. peilinwang@google.com clank-performance-team@google.com Records the hash of callers (file_name:function_name) that post delayed tasks with a delay longer than 25 minutes. Recorded in TaskQueueImpl::MakeDelayedTask when the DelayedTask is created. Subsampled with probability 1/1000. pasko@chromium.org joenotcharles@google.com Records true every time the underlying OS event successfully wakes up thread {ThreadName} from idle sleep. Avoids recording spurious OS wakeups: when no events are processed. This can happen because of timeouts when waiting. Also excludes samples for 'synthetic wakeups', such as when an event is discovered by BusyWaitOnEvent. In Finch experiments, enabling busy waiting should directly reduce the volume of recorded wakeups. anandrv@google.com clank-performance-team@google.com The wall time duration of busy-loops on the default message pump that successfully avoided sleeping because a task arrived. Recorded only on clients with high-resolution clocks. Subsampled with probability 1/1000. anandrv@google.com clank-performance-team@google.com The wall time duration of busy-loops on the default message pump that timed out without any task arriving. Recorded only on clients with high-resolution clocks. Subsampled with probability 1/1000. anandrv@google.com clank-performance-team@google.com Records the accuracy of the busy-loop heuristic on the default message pump. * True Positive: Heuristic predicted to busy loop and a task arrived within the max busy loop duration. * False Positive: Heuristic predicted to busy loop but no task arrived within the max busy loop duration. * True Negative: Heuristic predicted not to busy loop and no task arrived within the max busy loop duration. * False Negative: Heuristic predicted not to busy loop but a task arrived within the max busy loop duration. Subsampled with probability 1/1000. anandrv@google.com clank-performance-team@google.com The maximum busy-loop target duration that was configured on the default message pump. Recorded only on clients with high-resolution clocks. Subsampled with probability 1/1000. anandrv@google.com clank-performance-team@google.com Records whether busy-looping on the default message pump succeeded or not. Subsampled with probability 1/1000. gab@chromium.org fdoray@chromium.org spvm@chromium.org Records the number of milliseconds spent in each phase of pumping tasks on {NamedThread}. Each enum value can be analyzed for its total time or as a percentage relative to other phases. vmiura@chromium.org speed-metrics-dev@chromium.org chrome-analysis-team@google.com The time delta between the draw times of back-to-back BeginImplFrames, regardless of whether or not they result in a swap. The interval is only recorded when every BeginImplFrame wants to draw. Do not modify this metric in any way without contacting speed-metrics-dev@chromium.org AND chrome-analysis-team@google.com. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_HIGH_RESOLUTION_TIMES for the solution. kawasin@google.com joelaf@google.com The error types from schedqos feature in resourced. This is recorded each time the SetProcessState DBus request fails. The request rarely fails. kawasin@google.com joelaf@google.com The error types from schedqos feature in resourced. This is recorded each time the SetThreadState DBus request fails. The request rarely fails. olivierli@google.com etienneb@google.com Records the duration of an active period of less than 1 millisecond using ThreadController on {NamedThread}. Recorded when an active period ends. Sub-sampled to 0.1% of intervals. WARNING: This metric is not recorded on clients with low-resolution clocks, which means measurments are biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for additional details. olivierli@google.com etienneb@google.com Records the duration of an active period {Length} using ThreadController {NamedThread}. Recorded when an active period ends. Sub-sampled to 0.1% of intervals. olivierli@google.com etienneb@google.com Records the duration spent off-cpu during an active period of less than 1 millisecond using ThreadController on {NamedThread}. Recorded when an active period ends. Sub-sampled to 0.1% of intervals. WARNING: This metric is not recorded on clients with low-resolution clocks, which means measurments are biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for additional details. olivierli@google.com etienneb@google.com Records the duration spent off-cpu during an active period {Length} operiod using ThreadController on {NamedThread}. Recorded when an active period ends. Sub-sampled to 0.1% of intervals. olivierli@google.com etienneb@google.com Records the duration spent on-cpu during an active period of less than 1 millisecond using ThreadController on {NamedThread}. Recorded when an active period ends. Sub-sampled to 0.1% of intervals. WARNING: This metric is not recorded on clients with low-resolution clocks, which means measurments are biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for additional details. olivierli@google.com etienneb@google.com Records the duration spent on-cpu during an active period {Length} using ThreadController on {NamedThread}. Recorded when an active period ends. Sub-sampled to 0.1% of intervals. olivierli@google.com etienneb@google.com Records the percentage of time a thread stayed on-cpu during an active ThreadController period of less than 1 millisecond on {NamedThread}. Recorded when an active period ends. Sub-sampled to 0.1% of intervals. olivierli@google.com etienneb@google.com Records the percentage of time a thread stayed on-cpu during an active ThreadController period {Length} on {NamedThread}. Recorded when an active period ends. Sub-sampled to 0.1% of intervals. henrika@google.com handellm@google.com Records the percentage of time the main GPU thread stayed off-cpu during active periods relative to the total time since the last metric was stored. Recorded over a window of length one second and each sample is independent of the previous one, hence knowing the value of x[i] does not provide any information about x[i+1]. Example: if the main GPU thread has been in an active state for 200 ms during the last second and 50 ms was off-cpu, as sample of 5% is stored. In this example, the corresponding on-cpu sample would be 15%. NOTE: This metric is only recorded when the command-line flag enable-gpu-main-time-keeper-metrics is enabled. henrika@google.com handellm@google.com Records the percentage of time the main GPU thread stayed on-cpu during active periods relative to the total time since the last metric was stored. Recorded over a window of length one second and each sample is independent of the previous one, hence knowing the value of x[i] does not provide any information about x[i+1]. Example: if the main GPU thread has been in an active state for 200 ms during the last second and 150 ms was on-cpu, as sample of 15% is stored. In this example, the corresponding off-cpu sample would be 5%. NOTE: This metric is only recorded when the command-line flag enable-gpu-main-time-keeper-metrics is enabled. henrika@google.com handellm@google.com Records the percentage of time the main GPU thread is active relative to the total time since the last metric was stored. Recorded over a window of length one second and each sample is independent of the previous one, hence knowing the value of x[i] does not provide any information about x[i+1]. Example: if the main GPU thread has been in an active state for 200 ms during the last second, a sample of 20% will be stored. NOTE: This metric is only recorded when the command-line flag enable-gpu-main-time-keeper-metrics is enabled. olivierli@google.com etienneb@google.com Records the duration of an idle period of less than 1 millisecond using ThreadController on {NamedThread}. Recorded when an active period begins. Sub-sampled to 0.1% of intervals. WARNING: This metric is not recorded on clients with low-resolution clocks, which means measurments are biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for additional details. olivierli@google.com etienneb@google.com Records the duration of an idle period {Length} using ThreadController on {NamedThread}. Recorded when an active period begins. Sub-sampled to 0.1% of intervals. anandrv@google.com clank-performance-team@google.com The nice value of {ThreadName} in the browser process. Recorded only on Android. Sampled once every five minutes. anandrv@google.com clank-performance-team@google.com The nice value of {ThreadName} in the GPU process. Recorded only on Android. Sampled once every five minutes. anandrv@google.com clank-performance-team@google.com The nice value of {ThreadName} in a renderer process. Recorded only on Android. Sampled once every five minutes. spvm@chromium.org gab@chromium.org Records a hit when a thread pool worker thread woke up unnecessarily (when the first GetWork called by a WorkerThread post-wakeup doesn't return a task). This count can be compared between experiments aiming to reduce wakeups. Or, it could be used to derive wakeups/(foo) by using UMA formulas against other time-or-event-based metrics. {ThreadPoolName} {WorkerGroup}