Hi David, Ingo, Keith, Kier and all,
As the developer of PAPI, I can only reiterate what Ingo and David have
suggested. The user base of people wanting access to performance
counters has
greatly expanded. PAPI has now been out for over a year and a half and
we get pings from developers across the globe working with the
performance counters on
everything from performance tool development, to database tuning, to
feedback directed compilation.
For the Linux port, we originally (in 2.0 and 2.2) used David's patch
with some minor modifications that I made for inheritance of the MSR
when an option is set.
For 2.4 we have migrated to Mikael Petterson's excellent perfctr patch
which provides us with extrememly low latency access to the counters via
a memory mapped interface. The only outstanding issue with that patch as
far as PAPI goes is how MSR/counter inheritance is handled by threads
and making the virtualized TSC run freely from 'attach' time.
As far as a kernel interface goes, we need to remember that most
architectures allow the counters to be read in user mode, which lends
itself very nicely to the kind of implementation that Mikael has done.
Basically, reading the counters is a 2 step process: read the mmapped
virtual counters and add that to the contents of rdpmc(). This means
that (at least for the x86 series) the kernel interface only needs to
'guard' access to the MSR to make sure the user doesn't set up anything
pathological. This same kind of interface is also possible for the
UltraSparc. For other systems where a lower IPL is required, the
interface needs to be a fast-path syscall interface.
I would like to point out that this is not just something that us
hackers need, but now that multi-million dollar superclusters are being
sold by the dozen, hardware based performance analysis and tuning is a
real necessity. I know the TurboLinux folks are playing here, but no one
has come out an championed a kernel interface. In fact, there is at
least one commercial product (DEEP/MPI from PSRV) I know of that uses
the hardware counters (and PAPI for that matter) that is dependent upon
us academics to make sure we keep the kernel patch up to date.
Now, back to the subject at hand, if the NMI mechanism is coded
properly, we can also use it to generate statistical profiles instead of
emulating them in user land.
Well, that's all for now. If anyone is motivated to spearhead a formal
interface to the PMC's, please let us know.
Thanks for reading this novel,
-Philip Mucci
IBM Research
UTK Innovative Computing Lab.
David Mentré wrote:
>
> Ingo Molnar <mingo@elte.hu> writes:
>
> > that having all said, i'm not against a generic, nonpriviledged (kernel
> > based) performance counter API within the kernel (if there is demand), and
> > such an API should of course have close control over the contents of the
> > performance counter registers, and in this case the NMI oopser has to
> > cooperate. Something like doing per-process performance monitoring and
> > potentially switching the MSRs on task-switch.
>
> regarding perf. counters, there is also the PAPI initiative, standard
> *user level* API :
>
> Performance Data Standard and API
> http://icl.cs.utk.edu/projects/papi/
>
> Linux 2.2 and 2.4 (CVS) are actively supported with a patch. Probably
> PAPI developers would also be glad to have a standard linux kernel API.
>
> d.
> --
> David.Mentre@irisa.fr -- http://www.irisa.fr/prive/dmentre/
> Linux SMP HOWTO: http://www.irisa.fr/prive/dmentre/smp-howto/
> Opinions expressed here are only mine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:12 EST