* Mischa Jonker <mischa.jon...@synopsys.com> wrote:
> +/* The "generalized" performance events seem to really be a copy
> + of the available events on x86 processors; the mapping to ARC
> + events is not always possible 1-to-1. Fortunately, there doesn't
> + seem to be an exact definition for these events, so we can cheat
> + a bit where necessary */
> +static const char * const arc_pmu_ev_hw_map[] = {
> + /* cycles not in halted state */
> + [PERF_COUNT_HW_CPU_CYCLES] = "crun",
> + /* reference cycles not in halted state; also "crun" as we don't
> + do Dynamic Voltage/Frequency Scaling (yet) */
> + [PERF_COUNT_HW_REF_CPU_CYCLES] = "crun",
> + /* Unclear what this means, Intel uses 0x013c, which according to
> + their datasheet means "unhalted reference cycles". Don't ask
> + me what the difference is with PERF_COUNT_HW_REF_CPU_CYCLES */
> + [PERF_COUNT_HW_BUS_CYCLES] = "crun",
> + [PERF_COUNT_HW_INSTRUCTIONS] = "iall",
> + [PERF_COUNT_HW_BRANCH_MISSES] = "bpfail",
> + [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = "ijmp",
> + /* ARC can either measure stalls per pipeline stage, or all stalls
> + combined; for now we assign all stalls to STALLED_CYCLES_BACKEND
> + and all pipeline flushes (e.g. caused by mispredicts, etc.) to
> + STALLED_CYCLES_FRONTEND.
> +
> + We could start multiple performance counters and combine everything
> + afterwards, but that makes it complicated, and users can always
> + use PERF_TYPE_RAW.
> +
> + Note that I$ cache misses aren't counted by either of the two! */
Haven't really looked at the patch in detail, just noticed the following
nit, please use the customary (multi-line) comment style:
/*
* Comment .....
* ...... goes here.
*/
specified in Documentation/CodingStyle.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
