On 12/05/2017 01:57 PM, Stephane Eranian wrote: > > > On Tue, Dec 5, 2017 at 8:30 AM, Will Schmidt <will_schm...@vnet.ibm.com > <mailto:will_schm...@vnet.ibm.com>> wrote: > > On Tue, 2017-12-05 at 10:00 -0500, William Cohen wrote: > > On 12/05/2017 01:42 AM, Stephane Eranian wrote: > > > Will, > > > > > > There is something I am missing here. You are creating _ALT version > of events with the same event code. > > > What's the point of that? > > The event codes should be unique. The recent changes are mostly to add > _ALTx to the names to ensure they are unique enough. > More clarification below. > > > > There should not be duplicate event names in any event tables. The > validation checks verify this. > > > On PPC, I understand that the event code is manually crafted and > contains more than an event code. > > > So are you saying that sometimes, you want to specify an evnet > multiple times, but to do so, you need > > > to use different event codes? > > > Please clarify. > > > Thanks. > > > > Hi Stephane, > > > > I don't have the Power9 documentation (Will Schmidt, is there a public > > version of power 9 docs available now?), so I don't know the > > details of the contraints on how different event can (and cannot) be > > concurrently used. There was some earlier discussion on the papi > > mailing list about papi preset PAPI_L1_DCM being unusable on power9 > > because the PM_LD_MISS_L1 and PM_ST_MISS_L1 could not be used > > concurrently on power9. Power has some alternative codings for some > > of the events that can be used instead to allow these metrics to be > > gathered concurrently. Those alternative encodings were added to > > libpfm by: > > > > At a high-ish level, for ppc64*, there are 4 counters on which events > can be measured. Events are usually only valid on one of the four > counters. The leading 0x1.... through 0x4.... in the pme_code field tend > to indicate which counter the event is valid on. > If two events are both defined for the same counter, they won't work > concurrently. > > Ok, I get that. But I am questioning the design choice here. > The same kind of constraints exists on X86. The kernel solves this > by multiplexing the event because it knows the event constraints/. > > Here it appears the design choice was different. The kernel does not > know event constraints. They are encoded in the event code. Thus you > need to create events aliases where the counter index is different to > measure some events together and avoid multiplexing. > > That means the users needs to be aware of potential aliases and pick > the right list of event names to make this work. > > I get it now. > > Thanks.
Hi Stephane, I couuldn't find online information about the power9 performance monitoring hw. The closest I could find was for the power8. I expect that there are significant differences between them, but philosophically they have similar issues with event constraints. Looking at "11. Performance Monitor" chapter and "Appendix D. Performance Monitoring Events" of will give some idea how the power hardware is configured: https://www.setphaserstostun.org/power8/POWER8_UM_v1.3_16MAR2016_pub.pdf Looking at Appendix D" which register the code (lower 16-bits) is programmed makes a difference in what event is being monitored (00000100F2 vs 00000400F2). -Will ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
