Messages in this thread | | | Date | Fri, 12 Aug 2011 00:35:33 -0400 | From | Vince Weaver <> | Subject | Re: [patch] perf: ARMv7 wrong "branches" generalized instruction |
| |
On Thu, 11 Aug 2011, Ingo Molnar wrote:
> > * Will Deacon <will.deacon@arm.com> 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 stores.
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 doing..
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: > > *NOT AT THE EXPENSE OF THE COMMON CASE*. > > [...] > > 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?
Vince
| |