[perfmon2] intel westmere support
Hi, I have updated the libpfm4 GIT tree with support for the upcoming Intel Westmere processor (model 37, 44) as documented in Vol 3b Dec 2009. The update includes both core and uncore PMU, though, only core PMU is supported by perf_events. Perf_events Westmere support is not yet available in 2.6.33-rc7 but only in tip-x86. It will eventually show up in Linus' tree. As for perfmon, in the next coming days, I will also enable Westmere support in the perfmon kernel GIT tree (2.6.30) and in libpfm for perfmon (a.k.a. libpfm3). That will allow core and uncore PMU support. To get the latest libpfm4: git clone git://perfmon2.git.sourceforge.net/gitroot/perfmon2/libpfm4 -- 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
Re: [perfmon2] Perf_events support for Nehalem uncore events.
Gary, On Thu, Feb 11, 2010 at 9:51 PM, 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. > There are several events in this set that we view as being very important > when trying to > determine how memory is being accessed and what the impact of memory access > is on > an applications performance. > > We view this as a huge loss when we had to move from perfmon2 to > perf_events and I > am hoping you can tell me it is just a temporary regression. > > In addition this is probably not the best place to post questions about > perf_events, can you > point me to a better place to post these kind of questions ?? > The normal place would be LKML. -- 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
[perfmon2] Perf_events support for Nehalem uncore events.
Hi Stephane Do you happen to know if perf_events has any plans to support Nehalem uncore events ?? There are several events in this set that we view as being very important when trying to determine how memory is being accessed and what the impact of memory access is on an applications performance. We view this as a huge loss when we had to move from perfmon2 to perf_events and I am hoping you can tell me it is just a temporary regression. In addition this is probably not the best place to post questions about perf_events, can you point me to a better place to post these kind of questions ?? Thanks Gary stephane eranian wrote on 02/11/2010 09:09:46 AM: > > The update includes both core and uncore PMU, though, only core > PMU is supported by perf_events. > -- 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
Re: [perfmon2] Perf_events support for Nehalem uncore events.
Hi Stephane, On 2/11/2010 1:00 PM, stephane eranian wrote: > Gary, > > On Thu, Feb 11, 2010 at 9:51 PM, 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? 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. Any thoughts, concerns, alternative ideas, etc. would be appreciated, and I'm interested to hear your take on how to approach this issue. 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
Re: [perfmon2] Perf_events support for Nehalem uncore events.
On Thu, Feb 11, 2010 at 11:10 PM, Corey Ashford wrote: > Hi Stephane, > > On 2/11/2010 1:00 PM, stephane eranian wrote: >> >> Gary, >> >> On Thu, Feb 11, 2010 at 9:51 PM, 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. As mentioned, the kernel would have to enumerate all PMUs at boot time, or on hotplug event. -- 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
Re: [perfmon2] [RFC] perf_events: how to add Intel LBR support
On 10.02.10 17:01:45, Stephane Eranian wrote: > I was referring to the fact that if I enable LBR via a PERF_SAMPLE_* bit, I > will actually need more than one bit because there are configuration options. > I was not talking about event_attr.config. I am not sure how big a LBR sample would be, but couldn't you send the whole sample to the userland as a raw sample? If this is too much overhead and you need to configure the formate, you could set up this using a small part of the config value. > > The basic idea for IBS is to define special pmu events that have a > > different behaviour than standard events (on x86 these are performance > > counters). The 64 bit configuration value of such an event is simply > > marked as a special event. The pmu detects the type of the model > > specific event and passes its value to the hardware. Doing so you can > > pass any kind of configuration data to a certain pmu. > Isn't that what the event_attr.type field is used for? there is a RAW type. > I use it all the time. As for passing to the PMU specific code, this is > already what it does based on event_attr.type. I mean, you could setup the pmu with a raw config value. The samples you return are in raw format too. Doing so, you could put in all information, also that about the sample format into you configuration. Of course there must be a way for values more than 64 bits. The problem with the current x86 implementation is that it expects a raw config value in the performance counter format. To mark the config as different, I would simply introduce a bit in event_attr that marks it as special event. > > The sample data you get in this case could be either packed into the > > standard perf_event sampling format, or if this does not fit, the pmu > > may return raw samples in a special format the userland knows about. > > > There is a PERF_SAMPLE_RAW (used by tracing?). It can return opaque > data of variable length. > > There is a slight difference between IBS and LBR. LBR in itself does not > generate any interrupts. It has no associated period you arm. It is a free > running cyclic buffer. To be useful, it needs to be associated with a regular > counting event, e.g, BRANCH_INSTRUCTIONS_RETIRED. Thus, you > would need to set PERF_SAMPLE_TAKEN_BRANCH on this event, and > then you would expect the LBR data coming back as PERF_SAMPLE_RAW. > > > If you use the other approach with a dedicated event type. For instance: > > event.type = PERF_TYPE_HW_BRANCH; > event.config = PERF_HW_BRANCH:TAKEN:ANY > > I used a symbolic name to make things clearer (but it is the same model as > for the cache events). > > Then you need to group this event with BRANCH_INSTRUCTIONS_RETIRED > and set PERF_SAMPLE_GROUP to collect the values of the other member > of the group. In that case, the other member is LBR but it has a value that > is more than 64 bits. That does not work with the current code. There are several questions: How to attach additional setup options to an event? Grouping seems to be a solution for this. How to pass config values with more than 64 bits to the pmu? An extension of the api is probably needed, or grouping could work too. How to get samples back? The raw sample format is the best to use here. For IBS the difference is that the configuration has nothing to do with performance counters and a raw config value needs differen handling. -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: robert.rich...@amd.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
Re: [perfmon2] Perf_events support for Nehalem uncore events.
On 2/11/2010 2:19 PM, stephane eranian wrote: > On Thu, Feb 11, 2010 at 11:10 PM, Corey Ashford > wrote: >> Hi Stephane, >> >> On 2/11/2010 1:00 PM, stephane eranian wrote: >>> >>> Gary, >>> >>> On Thu, Feb 11, 2010 at 9:51 PM,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
