From: Ingo Molnar <mingo@elte.hu>
To: David Miller <davem@davemloft.net>
Cc: paulus@samba.org, tglx@linutronix.de,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
akpm@linux-foundation.org, eranian@googlemail.com,
dada1@cosmosbay.com, robert.richter@amd.com, arjan@infradead.org,
hpa@zytor.com, a.p.zijlstra@chello.nl, rostedt@goodmis.org
Subject: Re: [patch 0/3] [Announcement] Performance Counters for Linux
Date: Fri, 5 Dec 2008 14:25:12 +0100 [thread overview]
Message-ID: <20081205132512.GA18786@elte.hu> (raw)
In-Reply-To: <20081205.001520.79526444.davem@davemloft.net>
* 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
next prev parent reply other threads:[~2008-12-05 13:25 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-04 23:44 [patch 0/3] [Announcement] Performance Counters for Linux Thomas Gleixner
2008-12-04 23:44 ` [patch 1/3] performance counters: core code Thomas Gleixner
2008-12-05 10:55 ` Paul Mackerras
2008-12-05 11:20 ` Ingo Molnar
2008-12-04 23:44 ` [patch 2/3] performance counters: documentation Thomas Gleixner
2008-12-05 0:33 ` Paul Mackerras
2008-12-05 0:37 ` David Miller
2008-12-05 2:50 ` Arjan van de Ven
2008-12-05 3:26 ` David Miller
2008-12-05 2:33 ` Andi Kleen
2008-12-04 23:45 ` [patch 3/3] performance counters: x86 support Thomas Gleixner
2008-12-05 0:22 ` [patch 0/3] [Announcement] Performance Counters for Linux Paul Mackerras
2008-12-05 6:31 ` Ingo Molnar
2008-12-05 7:02 ` Arjan van de Ven
2008-12-05 7:52 ` David Miller
2008-12-05 7:03 ` Ingo Molnar
2008-12-05 7:03 ` Ingo Molnar
2008-12-05 7:16 ` Peter Zijlstra
2008-12-05 7:57 ` Paul Mackerras
2008-12-05 8:03 ` Peter Zijlstra
2008-12-05 8:07 ` David Miller
2008-12-05 8:11 ` Ingo Molnar
2008-12-05 8:17 ` David Miller
2008-12-05 8:24 ` Ingo Molnar
2008-12-05 8:27 ` David Miller
2008-12-05 8:42 ` Ingo Molnar
2008-12-05 8:49 ` David Miller
2008-12-05 12:13 ` Ingo Molnar
2008-12-05 12:13 ` Ingo Molnar
2008-12-05 12:39 ` Andi Kleen
2008-12-05 20:08 ` David Miller
2008-12-10 3:48 ` Paul Mundt
2008-12-10 4:42 ` Paul Mackerras
2008-12-10 8:43 ` Mikael Pettersson
2008-12-10 10:28 ` Andi Kleen
2008-12-10 10:23 ` Paul Mundt
2008-12-10 11:03 ` Andi Kleen
2008-12-10 11:03 ` Andi Kleen
2008-12-10 10:28 ` Andi Kleen
2008-12-05 15:00 ` Arjan van de Ven
2008-12-05 9:16 ` Paul Mackerras
2008-12-05 7:57 ` David Miller
2008-12-05 8:18 ` Ingo Molnar
2008-12-05 8:20 ` David Miller
2008-12-05 7:54 ` Paul Mackerras
2008-12-05 8:08 ` Ingo Molnar
2008-12-05 8:15 ` David Miller
2008-12-05 13:25 ` Ingo Molnar [this message]
2008-12-05 9:10 ` Paul Mackerras
2008-12-05 12:07 ` Ingo Molnar
2008-12-06 0:05 ` Paul Mackerras
2008-12-06 1:23 ` Mikael Pettersson
2008-12-06 12:34 ` Peter Zijlstra
2008-12-07 5:15 ` Paul Mackerras
2008-12-08 7:18 ` stephane eranian
2008-12-08 11:11 ` Ingo Molnar
2008-12-08 11:58 ` David Miller
2008-12-09 0:21 ` stephane eranian
2008-12-09 0:21 ` stephane eranian
2008-12-05 0:22 ` H. Peter Anvin
2008-12-05 0:43 ` Paul Mackerras
2008-12-05 1:12 ` David Miller
2008-12-05 6:10 ` Ingo Molnar
2008-12-05 7:50 ` David Miller
2008-12-05 9:34 ` Paul Mackerras
2008-12-05 10:41 ` Ingo Molnar
2008-12-05 10:05 ` Ingo Molnar
2008-12-05 3:30 ` Andrew Morton
2008-12-06 2:36 ` stephane eranian
2008-12-08 2:12 ` [perfmon2] [patch 0/3] [Announcement] Performance Counters forLinux Dan Terpstra
2008-12-10 16:27 ` [patch 0/3] [Announcement] Performance Counters for Linux Rob Fowler
2008-12-10 16:27 ` [perfmon2] " Rob Fowler
2008-12-10 17:11 ` Andi Kleen
2008-12-10 17:11 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081205132512.GA18786@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=eranian@googlemail.com \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=robert.richter@amd.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox