lkml.org 
[lkml]   [2011]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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



    \
     
     \ /
      Last update: 2011-08-12 06:39    [W:0.028 / U:119.096 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site