On 09/29/2010 10:17 AM, stephane eranian wrote: > On Wed, Sep 29, 2010 at 6:36 PM, Corey Ashford > <cjash...@linux.vnet.ibm.com> wrote: >> On 09/29/2010 12:33 AM, stephane eranian wrote: >>> >>> Corey, >>> >>> Please note that once libpfm4-1.0 is released, I'll post a patch >>> to link the perf tool directly with libpfm4. At that point, you will >>> not need your little evt2raw program to access any event encoding. >> >> When you say you'll post a patch, did you mean to LKML? I did this already >> and it was rejected in favor of a more long-term approach that uses sysfs >> for PMU and event naming. All of the details of that system are still very >> sketchy, but I don't think you'll be able to get Ingo et al. to commit such >> a patch. >> > > I don't want to have the full event tables in the kernel. There are about > 100 events on any Intel processors. No way this should go into the > kernel. I am not event talking about the modifiers or umask combinations. >
I have some misgivings about that approach too, but Ingo (mainly) and Peter Z. (to a lesser degree, I think) are against the idea of using a user-space library. I think their position is that the kernel knows (or could know) exactly which hardware events it's capable of supporting, and can expose those via sysfs, just as it knows which trace events, and hardware devices are connected. >>> >>> What's blocking release 1.0? >>> >>> 1- add support for OS-specific event attributes >>> 2- add Pentium 4 (Netburst) support >>> >>> For 1, the idea is to allow you to pass attributes which come from the >>> OS API and not the HW. For instance, the sampling period, the precise_ip >>> mode. The list of OS attributes for each event depends on the OS and the >>> event itself. Sometimes, there are several HW attributes which do overlap >>> with OS attributes, for instance u, k, precise_ip. The latter is connected >>> to >>> PEBS on Intel processors. The u, k in perf_events override those set in >>> HW. >>> >>> The reason 1- is delaying the release is because it may have some >>> implications >>> at the user level API of libpfm4. >>> >> >> That's interesting, and I can see where that would have use for us as well. >> For example, some of our Power-based systems have full hypervisors and some >> run the Linux kernel in hypervisor mode. >> > Well, yes, I want to get to a situation where I can say: > > perf stat -e inst_retired:any_p:c=1:i:u:F=1000:precise=2 That would be nice, and that's what the LKML patch I posted allowed. That was about a year ago now, I think. In theory, you could do similar via sysfs, via: perf stat -e /sys/device/cpu/cpu0/events/inst_retired:any_p:c=1:... The attribute part of that "event path" would be parsed by the kernel, as the attributes would be described in sysfs as well. To be clear though, no one yet has proposed a fully-fleshed-out sysfs-based solution which meets all of the above requirements... it's only been discussed with some hand-waving on LKML by Lin Ming, Robert Richter, and me. > > Yes, the core of the library should remain OS-API agnostic. Yep. > Thus it has to also export what the HW can do, e.g., user or > kernel priv levels. So there are some nasty corner cases where > modifiers from the HW and OS collide. This has to be handled > properly. I think it's not always clear what "proper" should mean too :-) > I also want to be able to connect libpfm4 to non perf_event > based OS, e.g., FreeBSD, Win32, and so on. Understood. Just out of curiosity, does Google make use of FreeBSD? - Corey ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
