[lkml]   [2011]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] perf events: Add stalled cycles generic event - PERF_COUNT_HW_STALLED_CYCLES

* Arun Sharma <> 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).


Your script:

> # ./
> 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

> 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

> 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 :-)



 \ /
  Last update: 2011-04-25 19:41    [W:0.125 / U:0.844 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site