perf wrong branches event on AMD
in [Kernel]
|
From: Arnaldo Carvalho de Melo on 1 Jul 2010 16:00 Em Thu, Jul 01, 2010 at 03:30:16PM -0400, Vince Weaver escreveu: > Hello > > while doing some performance counter validation tests on some assembly > language programs I noticed that the "branches:u" count was very wrong on > AMD machines. > > It looks like the wrong event was selected. > > This is why event selection needs to be in user-space... it could be fixed > instantly there, but the way things are done now it will take months to > years for this fix to filter down to those trying to use perf counters... Well, you can use: rNNN (see 'perf list --help' on how to encode it) [Raw hardware event descriptor] In the meantime. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 2 Jul 2010 07:40 On Thu, 2010-07-01 at 15:30 -0400, Vince Weaver wrote: > This is why event selection needs to be in user-space... it could be fixed > instantly there, but the way things are done now it will take months to > years for this fix to filter down to those trying to use perf counters... Last time I checked apt-get upgrade/yum upgrade simply upgraded everything, including kernels.. (and upgrades to userspace packages can take months too) Someone needs to build a new package and publish it, upgrading the kernel is no harder than upgrading any other. If you don't want to reboot, there's the -r option Arnaldo already mentioned. There's also the option of writing a kernel module to poke at the data table if you really really want to update a running kernel. If you think this is a really "important" feature you could even make a patch that exposes all these data tables to userspace through sysfs or whatever and see if people think its worth the effort. Personally I don't think people will ever use such a sysfs interface, but hey, that's my opinion. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Vince Weaver on 2 Jul 2010 10:20 On Fri, 2 Jul 2010, Peter Zijlstra wrote: > On Thu, 2010-07-01 at 15:30 -0400, Vince Weaver wrote: > > This is why event selection needs to be in user-space... it could be fixed > > instantly there, but the way things are done now it will take months to > > years for this fix to filter down to those trying to use perf counters... > > Last time I checked apt-get upgrade/yum upgrade simply upgraded > everything, including kernels.. (and upgrades to userspace packages can > take months too) The system I have this problem on is a large server used by many people, and has some fiddly hardware. The admins don't take kernel upgrades lightly. User-space libraries can be installed in my home directory, by me, with no changes to anyone else using the system. > If you don't want to reboot, there's the -r option Arnaldo already > mentioned. There's also the option of writing a kernel module to poke at > the data table if you really really want to update a running kernel. You think I have root on this machine? In any case, yes, there's the "-r" option. Fun. I get to modify all my scripts to have some complicated case... "if AMD machine and if kernel is new enough"... how new? It gets confusing once things get backported to stable. As far as I know there's no way to get a kernel to spit out what raw events it's using for the predefined events. Plus, the branches:u result is giving a *wrong* event with wrong values, not just a 0 count which might be suspicious. If the solution really is to use raw events in a case like this, I question why the predefined events are in the kernel at all. Pretty much anyone using the braches event on an AMD machine is going to be getting wrong results for all kernels between 2.6.31 and 2.6.35 and not even know it unless they read the kernel list. > If you think this is a really "important" feature you could even make a > patch that exposes all these data tables to userspace through sysfs or > whatever and see if people think its worth the effort. such a library already exists, called libpfm4. I use it when I can. Unfortunately perf is widely used and comes with the kernel. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 2 Jul 2010 10:30 On Fri, 2010-07-02 at 09:56 -0400, Vince Weaver wrote: > You think I have root on this machine? Well yeah,.. I'd not want a dev job and not have full access to the hardware. But then, maybe I'm picky. > In any case, yes, there's the "-r" option. Fun. I get to modify all my > scripts to have some complicated case... "if AMD machine and if kernel is > new enough"... how new? It gets confusing once things get backported to > stable. As far as I know there's no way to get a kernel to spit out what > raw events it's using for the predefined events. You can stick the knowledge in perf if you really want to.. something like the below, add something that parses cpuid or /proc/cpuinfo and you should be good. --- tools/perf/util/parse-events.c | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c index 4af5bd5..800f864 100644 --- a/tools/perf/util/parse-events.c +++ b/tools/perf/util/parse-events.c @@ -771,6 +771,22 @@ parse_event_symbols(const char **str, struct perf_event_attr *attr) modifier: parse_event_modifier(str, attr); + if (attr->type == PERF_TYPE_HARDWARE) { + switch (attr->config) { + case PERF_COUNT_HW_BRANCH_INSTRUCTIONS: + attr->type = PERF_TYPE_RAW; + attr->config = 0x00c2; + break; + case PERF_COUNT_HW_BRANCH_MISSES: + attr->type = PERF_TYPE_RAW; + attr->config = 0x00c3; + break; + + default: + break; + } + } + return ret; } > If the solution really is to use raw events in a case like this, I > question why the predefined events are in the kernel at all. Pretty much > anyone using the braches event on an AMD machine is going to be getting > wrong results for all kernels between 2.6.31 and 2.6.35 and not even know > it unless they read the kernel list. And how would it be different if it the data table lived in userspace? They'd still get the wrong thing unless they updated. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Vince Weaver on 2 Jul 2010 16:00
On Fri, 2 Jul 2010, Peter Zijlstra wrote: > On Fri, 2010-07-02 at 09:56 -0400, Vince Weaver wrote: > > You think I have root on this machine? > > Well yeah,.. I'd not want a dev job and not have full access to the > hardware. But then, maybe I'm picky. I can see how this support call would go now. Me: Hello, I need you to upgrade the kernel on the 2.332 petaflop machine with 37,376 processors so I can have the right branch counter on perf. Them: Umm... no. Me: Well then can I have root so I can patch the kernel on the fly? Them: <click> As a performance counter library developer, it is a bit frustrating having to keep a compatibility matrix in my head of all the perf events shortcomings. Especially since the users tend not to have admin access on their machines. Need to have at least 2.6.33 if you want multiplexing. Need to have 2.6.34 if you want Nehalem-EX. Need 2.6.35 if you want Pentium 4. Unfortunately most vendor kernels are stuck at 2.6.32 :( Now I'll have to remember whatever kenel the AMD branches fix is committed at. And there still isn't the Uncore support that everyone is clamoring for. > You can stick the knowledge in perf if you really want to.. something > like the below, add something that parses cpuid or /proc/cpuinfo and you > should be good. again though, doesn't this defeat the purpose of the whole idea of common named events? > And how would it be different if it the data table lived in userspace? > They'd still get the wrong thing unless they updated. because compiling and running an updated user-version of a library is possible. You can compile it in your home directory and link your tools against it. No need to bug the sysadmin. You can even use LD_PRELOAD to get other apps to link against it. Getting a kernel update installed is many orders of magnitude harder out in the real world. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |