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.
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. 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. >> 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. ------------------------------------------------------------------------------ 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
