Will, libpfm4 ONLY shows events supported by the host platform.
Sometimes it happens that between two processor models, many events overlap. On X86, for IVB and SNB, some events only exist in the server model yet I did not want to create a completely distinct table just for a handful of model specific events. Look and intel_ivb_events.h and umasks with .umodel field. In general libpfm4 defines one table per processor or processor family. So you could define pmu3, a57, x-gene tables. I assume there will be many derivatives of ARM64 thus many more variations of the event list. To avoid event duplicates in many tables, you could define the core architected events in a header file as a macro and include it in each model specific table. I have done that in the P6 processor family, for instance On Fri, Mar 7, 2014 at 8:57 PM, William Cohen <wco...@redhat.com> wrote: > On 03/07/2014 06:43 AM, Will Deacon wrote: >> On Thu, Mar 06, 2014 at 08:09:54PM +0000, William Cohen wrote: >>> On 11/04/2013 12:20 PM, Vince Weaver wrote: >>>> Hello >>>> >>>> here's an updated version of the arm64 patch. >>>> >>>> This version does not have any separate "arm64" naming, it just uses >>>> ARM_ARMv8. In theory you can boot a 32-bit kernel on an armv8 machine >>>> so the 64-bit distinction isn't needed anyway. >>>> >>>> This new patch also specifically targets the ARM Foundation simulator. >>>> In theory once the Cortex A53 and Cortex A57 documentation is released >>>> it will be easy enough to add the proper part numbers to the detection >>>> routines. >>>> >>> >>> Hi Vince and Stephane, >>> >>> I finally have access to a Applied Micro Circuits (APM) X-Gene machine to >>> try the patch out on and I have built a version of libpfm with this patch. >>> I have some questions on how some things should be handled. >>> >>> -There are currently three different pmu event sets I know of: the basic >>> pmu3 events in the aarhc64 manual, the cortex a57 events, and the APM >>> X-Gene events. The basic pmu3 event set is the smallest, the cortex a57 is >>> a larger set, and the APM X-Gene has some additional specific hardware >>> implementation events in addition to cortex a57. However, the cortex a57 >>> is not a pure superset of basic armv8 pmu3 event. Similarly the APM X-Gene >>> is not a pure super set of the cortex a57 (but it is close). Are there >>> suggestions on how to best handle these overlapping sets in the libpfm >>> event descriptions? Lowest common denominator? Just implement machine >>> have available (APM X-Gene) for the time being? >> >> They should be supersets in the sense that an event encoding from the basic >> PMUv3 events cannot be re-used for anything else. That is, it will be either >> implemented or reserved. >> >> Will >> > > Hi Will, > > Yes, the mapping names do not change encodings. The "not a pure superset" > was referring to whether the events are supported by a particular processor > implementation. Some people might be disappointed in seeing events listed > that are not actually implement or supported on a particular processors > implementation. > > -Will > > ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
