PerformanceMonitor: Add a new UMA histograms to track average CPU utilization

chrome/browser/performance_monitor/process_metrics_history.cc

Index: chrome/browser/performance_monitor/process_metrics_history.cc
diff --git a/chrome/browser/performance_monitor/process_metrics_history.cc b/chrome/browser/performance_monitor/process_metrics_history.cc
index 9ac206fb36151817a4ccbe446fb28fab2d91d2f6..38c1e417fa4cb66b52e1f9850d022d3b1606aac3 100644
--- a/chrome/browser/performance_monitor/process_metrics_history.cc
+++ b/chrome/browser/performance_monitor/process_metrics_history.cc
@@ -52,7 +52,7 @@ void ProcessMetricsHistory::Initialize(base::ProcessHandle process_handle,
 }
 
 void ProcessMetricsHistory::SampleMetrics() {
-  double cpu_usage = process_metrics_->GetCPUUsage();
+  double cpu_usage = process_metrics_->GetPlatformIndependentCPUUsage();
   min_cpu_usage_ = std::min(min_cpu_usage_, cpu_usage);
   accumulated_cpu_usage_ += cpu_usage;
 
@@ -74,9 +74,15 @@ void ProcessMetricsHistory::EndOfCycle() {
 
 void ProcessMetricsHistory::RunPerformanceTriggers() {
   // As an initial step, we only care about browser processes.
-  if (process_type_ != content::PROCESS_TYPE_BROWSER)
+  if (process_type_ != content::PROCESS_TYPE_BROWSER || sample_count_ == 0)
     return;
 
+  // We scale up to the equivalent of 64 CPU cores fully loaded. More than this
+  // doesn't really matter, as we're already in a terrible place.
+  UMA_HISTOGRAM_CUSTOM_COUNTS("PerformanceMonitor.AverageCPU.BrowserProcess",

[jar (doing other things), 2013/10/22 22:30:03]

This may be interesting to look at.... but it is hard to get a handle on
"average" or "typical" CPU usage.  The hassle is that you could avoid measuring
this when the user was "not busy," but that would be biased, or you could do it
"intermittently," but that gets lots of samples by users that "run for a long
time," even if they don't do "that much work" in the browser.

We'll see what this histogram shows.... but I suspect you'll have a hard time
interpreting the data meaningfully. :-/

We have a similar problem trying ot look at (for example) memory usage.  The
issue of when to sample is the big confusing gotcha.

[oystein (OOO til 10th of July), 2013/10/24 14:47:56]

Definitely some good points, and to be honest I'm not quite sure what we'll
find. I think what I most hope to gain from this is as a form of a canary; if
there's many instances where the browser process uses a large amount of CPU over
time (this is averages over every two minutes) we can be reasonably sure there's
something wrong, so at least this might tell us the *scope* of the problem and
hence how much effort to invest into further investigation.

+                              accumulated_cpu_usage_ / sample_count_,
+                              0, 6400, 50);
+
   // If CPU usage has consistently been above our threshold,
   // we *may* have an issue.
   if (min_cpu_usage_ > kHighCPUUtilizationThreshold)