Re: [PATCH] perf events: Add stalled cycles generic event - PERF_COUNT_HW_STALLED_CYCLES

[Ingo Molnar <mingo@elte.hu>]

* Arun Sharma <asharma@fb.com> wrote:

> On Sat, Apr 23, 2011 at 10:14:09PM +0200, Ingo Molnar wrote:
> > 
> > The new PERF_COUNT_HW_STALLED_CYCLES event tries to approximate
> > cycles the CPU does nothing useful, because it is stalled on a
> > cache-miss or some other condition.
> 
> Conceptually looks fine. I'd prefer a more precise name such as: 
> PERF_COUNT_EXECUTION_STALLED_CYCLES (to differentiate from frontend or 
> retirement stalls).

Ok.

Your script:

> # ./analyze.py
> Percent idle: 27%
>         Retirement Stalls: 82%
>         Backend Stalls: 0%
>         Frontend Stalls: 62%
>         Instruction Starvation: 62%
>         icache stalls: 0%
> 
> does give me a signal about where to look. The script below is
> a quick and dirty hack. I haven't really validated it with 
> many workloads. I'm posting it here anyway hoping that it'd
> result in better kernel support for these types of analyses.

Is pretty useful IMO.

The frontend/backend characterisation is pretty generic - most modern CPUs 
share that and have similar events.

So we could try to generalize these and get most of the statistics your script 
outputs.

> Even if we cover this with various generic PERF_COUNT_*STALL events,
> we'll still have a need for other events:
> 
> * Things that give info about instruction mixes.
> 
>   Ratio of {loads, stores, floating point, branches, conditional branches}
>   to total instructions.

We have this at least partially covered, but yeah, we stopped short of covering 
all instruction types so complete ratios cannot be built yet.

> * Activity related to micro architecture specific caches
> 
>   People using -funroll-loops may have a significant performance opportunity.
>   But it's hard to spot bottlenecks in the instruction decoder.
> 
> * Monitoring traffic on Hypertransport/QPI links

Cross-node accesses ought to be covered by Peter's RFC patch. In terms of 
isolating cross-CPU cache accesses i suspect we could do that too if it really 
matters to analysis in practice.

Basically the way to go about it are the testcases you wrote - they demonstrate 
the utility of a given type of event - and that justifies generalization as 
well.

> Like you observe, most people will not look at these events, so
> focusing on getting the common events right makes sense. But I
> still like access to all events (either via a mapping file or
> a library such as libpfm4). Hiding them in "perf list" sounds
> like a reasonable way of keeping complexity out.

Yes. We have access to raw events for relatively obscure (or too CPU dependent) 
events - but what we do not want to do is to extend that space without adding 
*any* generic event in essence. If something like offcore or uncore PMU support 
is useful enough to be in the kernel, then it should also be useful enough to 
gain generic events.

> PS: branch-misses:pp was spot on for the example above.

heh :-)

Thanks,

	Ingo