stephane eranian <eran...@googlemail.com> wrote on 06/04/2009 12:53:02 AM: > Corey, > > On Wed, Jun 3, 2009 at 1:22 AM, Corey Ashford > <cjash...@linux.vnet.ibm.com> wrote: > > > > It seems like you could call the kernel-specific code for event numbers > > greater than the pmu-specific hardware event numbers. Basically, you just > > need a way to plug in kernel-specific code that knows about the extra events > > exposed by it. Something like: > > > > int pfm_kernel_get_num_events() > > char *pfm_kernel_get_event(int event); > > > > For PCL, pfm_kernel_get_num_events() would return the number of software > > events + the number of generic events. libpfm would number these events > > last_pmu_hardware_event + 1 .. (last_pmu_hardware_event + > > pfm_kernel_get_num_events()). > > > > So the "linearizing" of the PCL events into a single space (rather than a > > separate software and generalized events) would be done by the PCL > > kernel-specific code. And the ordering of the PMU-specific and > > kernel-specific code would be done by the PCL generic code. > > > Yes, this is one solution. But it would have to be implemented by the > libpfm generic layer, not the PCL specific layer. >
I don't understand this reasoning, unless we are really saying the same thing. If libpfm was being layered on top of a different kernel implementation (not PCL), which had, say, six event spaces, would you still want the generic layer trying to deal with six event spaces, or should the kernel-specific layer deal with unifying those six spaces? To me, this is best dealt with in the kernel-specific layer. > PCL generic events would only be activated if libpfm detects that it is > running on a PCL-enabled kernel. Otherwise it would run without any > generic events. On a PCL-kernel, call pfm_dispatch_events() on > generic PCL events would fail. Would you need a concept of "generic events" at all, if you left it to the kernel layer to supply any additional events it knows about (on top of the PMU-specific ones that the the generic libpfm arch-specific code knows about)? If the kernel layer presents a single list of extra events it can handle to the libpfm generic layer, I'm not sure what else you need. Of course, this would be complicated by any attributes that would be needed by these events, but kernel-specific parsing routines could be supplied as well. > But here is another issue with PCL generic events. The generic HW > events such as PERF_COUNT_CPU_CYCLES amd such. For some > PMU models, there may not be any mapping. The kernel can return > an error for certain events. But what about libpfm? If we implement > all PCL generic HW events in a generic layer, then we would still need > to customize on a PMU-basis to turn off certain event which we know > are not mapped on the host PMU. I think it would be pretty confusing > to have libpfm let you use PERF_COUNT_LAST_LEVEL_CACHE_MISSES > if the PCL kernel has no mapping for it. Ok, so here we have a combination where the kernel-specific layer may not know that a particular generic event is not supported on the arch and/or PMU. Perhaps at start up time, the kernel-specific layer could query all of the generic events in PCL and find out which ones are supported, then present only the supported ones to the generic layer. This would cost some start up time. > > >> I did talk to Phil about this a while ago. It seems in PAPI they also > >> maintain > >> a hardcoded version. You can then setup PAPI to use either internal vs. > >> external > >> or external if is exists otherwise internal. That provides maximum > >> flexibility. > >> But then, of course, it does not address the size problem, it actually > >> make it > >> worse because you have the hardcoded tables AND the XML logic. > > > > I don't think PAPI's solution really solves the "quick load time + small > > foot print" issue for libpfm. If you just used caching, I think it solves > > both problems, but would require that the XML file be available somewhere > > when libpfm is loaded up the first time. If the XML file is never modified > > from then on, you'd always get the cached up data structure sitting in a > > file ready to be mmap'd into libpfm's space. > > > It is solved if in a large cluster PAPI is configured to always use > the hardcoded > event table but at the price of losing the flexibility of the external file. Right. But if you cache up into a file the event data that was stored as a result of processing the XML file, it would essentially be a C array of event data, nearly identical to the hard-coded arrays what we have now. You only have to parse the XML file once (until someone changes the XML file). You would have to read in or mmap one additional file at start up, but the file would be small and require no processing. Also, it might make sense to have a separate XML (and cache) for representing the kernel-specific (e.g. PCL generic and software) events. ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
