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

* David Miller <davem@davemloft.net> 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.

Ingo


\
 
 \ /
  Last update: 2008-12-05 14:29    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site