Will, Forgot to answer the other questions
On Thu, Mar 6, 2014 at 9:09 PM, William Cohen <wco...@redhat.com> 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? > >-Suggestions on the naming conventions for .desc and name fields of >pfmlib_pmu_t for armv8 processors? > > -Shouldn't the patch also implement some thing in libpfm/tests/validate_amr.c > to check that libpfm can do encoding for armv8? Are there guidelines on what > should be in the validate tests? > Yes, we need a validate_arm64.c test suite. ------------------------------------------------------------------------------ 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
