Re: [PATCH] perf wrong branches event on AMD

[Vince Weaver]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/