On 2/11/2010 2:19 PM, stephane eranian wrote: > On Thu, Feb 11, 2010 at 11:10 PM, Corey Ashford > <cjash...@linux.vnet.ibm.com> wrote: >> Hi Stephane, >> >> On 2/11/2010 1:00 PM, stephane eranian wrote: >>> >>> Gary, >>> >>> On Thu, Feb 11, 2010 at 9:51 PM,<gary.m...@bull.com> wrote: >>>> >>>> Hi Stephane >>>> >>>> Do you happen to know if perf_events has any plans to support Nehalem >>>> uncore events ?? >>>> >>> Well, I don't know if anyone is working on this. But this is definitively >>> on >>> my list of things to add. I don't like regressions! >>> >>> As you may have seen I started fixing some of these regressions myself >>> by posting patches to LKML. The first priority was correct event -> >>> counter >>> assignment. This is almost done now (at least on x86-tip). Next step is to >>> add the non-standard features, such as PEBS, LBR, uncore, offcore and >>> the likes. They will all be implemented because they are important to many >>> users. >>> >> >> I'm jazzed to see that you are considering adding support to perf_events for >> offcore PMUs. Have you had a chance to think about the fuzzy proposal I >> made on LKML regarding the addressing of offcore PMUs, or even uncore PMUs >> where there are multiple instances of the same PMU type? >> > I think the current PMU naming scheme is not flexible enough. Clearly, it does > not address PMU beyond the CPU socket. For existing uncore PMU on Nehalem, > for instance, we can get by by using the CPU as a hint. But we need something > more flexible. > >> Peter Zijlstra's idea is to add another field to the perf_event_attr struct, >> .pmu_id, which is a (char *) pointing to a pathname in /sys/devices, and >> directly at a PMU entry which contains a PMU id which can be used to both >> determine which PMU is being referred to and what type it is. Of course, >> these new PMU entries in /sys/devices would need to be added. >> > Yes, you need some enumeration of the available PMUs in sysfs. I would > rather pass a file descriptor to the sysfs file rather that the > pathname. It makes > is easier to handle in the kernel. > >> Any thoughts, concerns, alternative ideas, etc. would be appreciated, and >> I'm interested to hear your take on how to approach this issue. >> > My choice would be pass a fd to a sysfs file designating the resource.
Ah, so the user would first open the sysfs file using open(), and then pass that fd in attr.pmu_fd (or similar name). This sounds good. The only downside I see about this is that it would require that in the future, any PMU addressing would have to use a file descriptor rather than a more generalized string [which could be intrerpeted as a sysfs pathname for the foreseeable future]. On the other hand, error handling would be more tricky with a string because now we have all of the error codes having to do with open() to somehow return to the user and make unique from the event-related error codes. > As mentioned, the kernel would have to enumerate all PMUs at boot time, > or on hotplug event. Yep. It does something similar already with enumerating CPUs, I/O devices and so forth... so perhaps only a fairly minor addition would be needed for most existing systems. Thanks for your input, -- Regards, - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 cjash...@us.ibm.com ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
