[lkml]   [2008]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/3] [Announcement] Performance Counters for Linux

    * David Miller <> wrote:

    > > > Isn't it two separate read() calls to read the two counters? If
    > > > so, the only way the two values are actually going to correspond to
    > > > the same point in time is if the task being monitored is stopped.
    > > > In which case the monitoring task needs to use ptrace or something
    > > > similar in order to make sure that the monitored task is actually
    > > > stopped.
    > >
    > > It doesnt matter in practice.
    > Yes it DOES!
    > If I want to know if a code block triggers event X or Y, and your read
    > call triggers one of those events, I can't figure out the answer to my
    > profiling problem.

    ( this misunderstanding of yours has been cleared up in a later mail:
    reading a counter causes events in the monitoring context, not in the
    monitored context. )

    > That is completely fundamental to all of this. And this is why this
    > proposal is a non-workable solution.
    > > Also, look at our code: we buffer notification events and do not have
    > > to stop the thread for recording the context information.
    > But that's what monitoring libraries want, they want to stop the task
    > and inspect it.
    > Look at the PAPI library. If you can't implement what that thing
    > provides, all the real users of profiling information can't use this
    > stuff.

    We have looked, and the PAPI library can be implemented on top of our
    system call as well - just like it was implemented on top of the perfctr
    driver and like it was implemented ontop of "perfmon-full".

    PAPI is a relatively simple wrapper around OS level performance counter
    facilities. Both the high level counter abstraction
    (PAPI_start_counters() & friends) and the low level PAPI abstraction
    (PAPI event sets, PAPI_attach/detach) can be readily implemented via the
    use of our performance counter subsystem facilities. (In addition to all
    the facilities around PAPI event enumeration.)

    PAPI has about 100 functions - if you think our design does not fit it
    for some fundamental reason then please point out exactly which
    functionality (which PAPI function call) cannot be done.

    Perfmon needlessly complicated their design by exposing user-space to a
    'performance counter context' and other lowlevel details that should not
    and must not be handled at the ABI level. The PAPI interfaces do not
    force that design choice in any way. It's a plain unnecessary
    complication that permeates the whole perfmon code.


     \ /
      Last update: 2008-12-05 14:29    [W:0.029 / U:56.368 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site