Messages in this thread | | | Date | Tue, 03 Oct 2000 12:46:34 -0400 | From | "Philip J. Mucci" <> | Subject | Re: [patch] enabling APIC and NMI watchdog on UP systems |
| |
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/
| |