Re: [patch] perf: ARMv7 wrong "branches" generalized instruction

From: Vince Weaver
Date: Fri Aug 12 2011 - 00:35:58 EST

On Thu, 11 Aug 2011, Ingo Molnar wrote:

> * Will Deacon <will.deacon@xxxxxxx> wrote:
> So what you and Vince are suggesting, to dumb down the kernel parts
> of perf and force users into raw or microarchitecture specific events
> actually *reduces* the user-base very significantly - while in
> practice even just cycles, instructions and branches level analysis
> handles 99% of the everyday performance analysis needs ...

No, what I want are the generalized events to accurately describe what is
being measured.

To do this properly you need a lot more granularity. PAPI for example has
100+ generalized events, some of which require multiple hardware events
to be combined to get the desired outcome.

Having a "branch" event like that on ARM that ignores not-taken events is
going to drive you nuts when you are trying to sample in your code to
find out why the branch miss rate is so high and you want to find the loop
exits that are predicted poorly (but can't find them because loop exits
tend to be not-taken branches).

Having a "L1-dcache-load" event that includes stores (like on current AMD)
will drive you nuts if you are debugging code and it shows that somehow
these loads are triggering cache-coherency invalidates when you know that
usually only stores can do so, and why would a load only event count

Having a tool that gives misleading names to things would be like if I
gave some poor user a copy of gdb that silently set breakpoints a random
offset from where the actueal breakpoint. Sure it probably correlates to
where you want the code to stop, but it's not what the tool says it is

So either come up with finer-grained generalized events, or else do a
better job of picking them. The fact that my _extremely_ simple
validation tests keep turning up problems like this indicate that no one
bothered checking these events before they shoved them in the kernel.

Once in, these bad events linger for years and it's not even possible
to tell from userspace what raw even a generalized event maps to.
So anyone who cares is going to use a tool that uses raw events anyway.

(Note I am not saying they'll calculate the raw hex vaue themselves.
They'll use a pre-existing tool written by your maligned 1% power
users that will pick the proper raw event for them.)

> We saw how the "push CPU specific events to users and tooling"
> concept didn't work with oprofile - why do we have to re-discuss this
> part of failed Linux history again and again?

No one is arguing for oprofile. libpfm4/PAPI or a tool like pfmon, sure.

> The approach Vince and you are suggesting is literally sacrificing
> 99% of utility for 1% of the users - a not very smart approach. I
> don't mind accomodating the needs of 1% of power-users (at all), but:
> [...]
> We literally have more than 7 million lines of drivers/* code that
> provides generic abstractions - not just a few thousand lines of raw
> PCI operations space where user-space can write magic values to ...
> [...]
> It's the *job* of the kernel to abstract things away, we don't shy
> away from that ...

I get the impression if you were the graphics maintainer you'd specify all
drivers should use a 1024x768x16bpp generic abstraction and dither or
scale all devices to match this. This would be a nice abstraction that
would make graphics programming oh so much easier for the casual
programmer and it provides 99% of what most users want. The 1% of power
users are unimportant.

Also one could only use officialy blessed list of colors appearing in
some obscure file under /sys.

Also access to 3D functionality would be blocked until the people wanting
3D had properly developed a generic concept of the color "mauve" that
could be applied across the board, even on black+white only hardware.

> So having generic events is not some fancy, unused property, but a
> pretty important measurement aspect of perf.

perf the userspace tool or perf_event the kernel ABI?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at