[lkml]   [2008]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] Performance Counters for Linux, v3

    I don't think you understand what libpfm actually does and therefore
    you rush to the wrong conclusion.

    At its core, libpfm does NOT know anything about the perfmon kernel API.

    I think you missed that, unfortunately.

    It is a helper library which helps tool writer solves the event-> code
    -> counter assignment problems.
    That's it. It does not make any perfmon syscall at ALL to do that.
    Proof is people have been using it on
    Windows, I can also use it on MacOS.

    Looking at your proposal, you think you won't need such a library and
    that the kernel is
    going to do all this for you. Let's go back to your kerneltop program:

    KernelTop Options (up to 4 event types can be specified):

    -e EID --event_id=EID # event type ID [default: 0]
    0: CPU cycles
    1: instructions
    2: cache accesses
    3: cache misses
    4: branch instructions
    5: branch prediction misses
    < 0: raw CPU events

    Looks like I can do:

    $ kerneltop --event_id=-0x510088

    You think users are going to come up with 0x510088 out of the blue?

    I want to say:

    $ kerneltop --event_id=BR_INST_EXEC --plm=user

    Where do you think they are going to get that from?

    The kernel or a helper user library?

    Do not denigrate other people's software without understanding what it does.

    On Sat, Dec 13, 2008 at 12:17 PM, Peter Zijlstra <> wrote:
    > On Fri, 2008-12-12 at 18:42 +0100, stephane eranian wrote:
    >> In fact, I know tools which do not even need a library.
    > By your own saying, the problem solved by libperfmon is a hard problem
    > (and I fully understand that).
    > Now you say there is software out there that doesn't use libperfmon,
    > that means they'll have to duplicate that functionality.
    > And only commercial software has a clear gain by wastefully duplicating
    > that effort. This means there is an active commercial interest to not
    > make perfmon the best technical solution there is, which is contrary to
    > the very thing Linux is about.
    > What is worse, you defend that:
    >> Go ask end-users what they think of that?
    >> You don't even need a library. All of this could be integrated into the tool.
    >> New processor, just go download the updated version of the tool.
    > No! what people want is their problem fixed - no matter how. That is one
    > of the powers of FOSS, you can fix your problems in any way suitable.
    > Would it not be much better if those folks duped into using a binary
    > only product only had to upgrade their FOSS kernel, instead of possibly
    > forking over more $$$ for an upgrade?
    > You have just irrevocably proven to me this needs to go into the kernel,
    > as the design of perfmon is little more than a GPL circumvention device
    > - independent of whether you are aware of that or not.
    > For that I hereby fully NAK perfmon
    > Nacked-by: Peter Zijlstra <>

     \ /
      Last update: 2008-12-13 18:47    [W:0.025 / U:1.676 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site