PS: I selected a lot of tracing-named components as I am not sure of the correct one for this problem. Please trim down as needed.

Looks like tracing issue. @alph, could you take a look and forward it if needed?

Unfortunately, this is working as intended, but I agree that it's confusing behavior. The CPU metric basically uses the CPU time of all collected trace events to come up with the most accurate CPU usage graph possible. Because of this, it basically means that collecting more trace events will give strictly higher CPU usage, and collecting no trace events will indicate 0 CPU usage.

Looks like a trace-viewer issue. Nothing to do with DevTools.

Do you have suggestions for how this could be improved to be clearer? This graph represents the CPU usage as estimated via trace events that have been recorded in the trace. By definition, the more categories that you trace, the more data you'll have to flesh out that number. From my understanding, adding the "toplevel" category *should* be sufficient for getting all relevant CPU use slices.

My suggestions might be biased to my specific use case but they are (in decreasing priority order):

1) Provide a scale to the CPU graph: does it go from 0 to 100 % CPU usage? Without this information I can't asses what it anything plotted there represents and it becomes a meaningless graph.

2) Do full CPU usage recording independent of selected categories. I would think that when one is looking at that graph it's more useful to be able to compare what's being traced against all the rest than to only itself.

I think that 

"2) Do full CPU usage recording independent of selected categories. I would think that when one is looking at that graph it's more useful to be able to compare what's being traced against all the rest than to only itself."

 is the clear best solution, but the tricky part is understanding *how* we do that. Essentially, our instantaneous CPU use graph comes from instrumenting as many entry points to Chrome code as we can possibly find. In theory, the "toplevel" category is exactly what you're asking for, but we don't have a whole lot of confidence that we've actually identified all of Chrome's entry points. We've instrumented some of the big ones (e.g. MessageLoop::RunTask), but what about smaller ones, like when Chrome registers a callback with a system call? Right now, we don't have any means to verify that Chrome's purported CPU usage is accurate, and if there's anything we've realized since we set out in the benchmarking space, it's that if you're not measuring something, it's probably not doing what you want it to.

Marking this as available given the fact that I don't focus on power/CPU anymore.