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

    * 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


    \
     
     \ /
      Last update: 2011-04-25 19:41    [W:1.858 / U:0.252 seconds]
    ©2003-2014 Jasper Spaans. Advertise on this site