I was going to add UMA for long tasks -- this would make that unnecessary -- Great!
Although if you are sampling then we should make sure that all the long tasks (>50ms) get recorded

We couldn't sample some tasks but not others without introducing a bunch of bias.

We could sample for the "all the tasks" metric, but not sample for the "long tasks" metric.

What's wrong with sampling for the long tasks metric? Do we expect to have few enough long tasks that we wouldn't get enough data?

 

Doesn't sampling by task (vs. periodically i.e. by time) inherently bias against long tasks?
I think it depends on how you want to consume the data -- free to sample as you need, for your case.

Depends on what data you're trying to collect!

If you're trying to figure out what length of task is keeping the CPU busy in general, then sampling per task is broken. If you're just trying to get an idea of how many short tasks there are compared to how many long tasks there are, then sampling doesn't introduce bias.

Recording all task times is biased against long tasks in exactly the same way, isn't it? 

> If you're trying to figure out what length of task is keeping the CPU busy in general, then sampling per task is broken. If you're just trying to get an idea of how many short tasks there are compared to how many long tasks there are, then sampling doesn't introduce bias.

I think this is correct. Also, if we have an unbiased sample of number of tasks 
with each duration wouldn't we be able to estimate what is keeping the CPU busy? e.g., it is a function of num tasks with duration D * D.   

Sandra, sunyunjia@, is going to implement this. :)

Yep SG. 
Personally I'm interested in an UMA for impact of long tasks in terms of keeping CPU busy.
I'll think about what the right instrumentation is -- ideas welcome :)

If we're interested in what's keeping the CPU busy, we probably want something where the denominator is time. We could add two metrics:
• Per second, what fraction of the time was spent in tasks < 50ms long
• Per second, what fraction of the time was spent in tasks > 50ms long

That should be easy to build on top of the task queueing time estimator.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1aca73dda839f813d2a4d6fbcf654ed488a197dd

commit 1aca73dda839f813d2a4d6fbcf654ed488a197dd
Author: sunyunjia <sunyunjia@chromium.org>
Date: Wed Aug 03 20:13:55 2016

Report the duration of sampled tasks with histogram.

BUG= 630688 

Review-Url: https://codereview.chromium.org/2184023002
Cr-Commit-Position: refs/heads/master@{#409606}

[modify] https://crrev.com/1aca73dda839f813d2a4d6fbcf654ed488a197dd/components/scheduler/renderer/renderer_scheduler_impl.cc
[modify] https://crrev.com/1aca73dda839f813d2a4d6fbcf654ed488a197dd/tools/metrics/histograms/histograms.xml