On Mon, 21 Oct 2013, William Cohen wrote:
> Yes, armv8_pmuv3 seems a bit verbose. The kernel has similar naming in
> arch/arm64/kernel/perf_events.c Would it be sane just to group arm
> performance counters as arm_pmuvN, where N is 1, 2, or 3?
well, the issue is we support counters that pre-date pmuv1.
and we possibly currently have armv7 pmuv2 events (cortex-a15)
in the pmuv1 file. Hmmm.
> > + {.name = "CHAIN",
> > + .modmsk = ARMV7_A15_ATTRS,
> > + .code = 0x1e,
> > + .desc = "For odd counters, increment for each overflow of preceding
> > event-numbered counter. For even-numbered counters, no increment"
>
> The "CHAIN" event appears to be used to get wider counters from the
> 32-bit counters availble. However, it doesn't make sense to code the
> "CHAIN" event in libpfm because the perf interface doesn't have
> control where to place the counters with the perf interface.
It's still good to have it in libpfm4 so one can easily find the encoding
with tools like "showevtinfo" to be used with perf raw events.
It's true perf_event isn't really condusive to this type of event
currently, but it might eventually.
> "D6.10.5 Required events" section of the aarch64 manual indicates that
> some of the events may be omitted in some implmentations and "D6.10.6
> IMPLEMENTATION DEFINED event numbers" of the aarch manual indicates that
> some armv8 implmentations may have additional events. Is there some way
> in libpfm to determine at runtime which specific arm implementation the
> code is running on and enable/disable certain events? I know that x86
> can use the CPUID instruction to get that information.
yes, we currently parse /proc/cpuinfo and get the "CPU part" field.
That's how we differentiate Cortex A8/A9/A15, etc. We can do that
too if we ever get real hardware...
> According to the aarch64 machine "G4.4.9 PMEVTYPER<n>, Performance
> Monitors Event Type Registers, n = 0 - 30" and "I1.2.19
> PMEVTYPER<n>_EL0, Performance Monitors Event Type Registers, n = 0 - 30"
> the event specifier "evtCount" is 10 bits in size. rather than 8 bits
> for armv7. All of the currentlly listed events for armv8 fit in 8-bit,
> just thinking need to be careful about this when some implmentation
> specific events are defined with the upper 2 bits set.
Do we currently mask things in libpfm4?
We should maybe verify the perf_event interface, as from what I gather it
was very much a cut-and-paste of the armv7 code with a few fixes.
Vince
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
