Re: [Perfctr-devel] Re: quick overview of the perfmon2 interface

[John Reiser <jreiser@BitWagon.com>]

Christoph Hellwig wrote:
> On Thu, Dec 22, 2005 at 10:37:56AM -0500, William Cohen wrote:
> 
>>Both OProfile and PAPI are open source and could use such an performance 
>>monitoring interface.
>>
>>One of the problems right now is there is a patchwork of performance 
>>monitoring support. Each instrumentation system has its own set of 
>>drivers/patches. Few have support integrated into the kernel, e.g. 
>>OProfile. However, the OProfile driver provides only a subset of the 
>>performance monitoring support, system-wide sampling. The OProfile 
>>driver doesn't allow per-thread monitoring or stopwatch style 
>>measurement, which can be very useful for some performance monitoring 
>>applications.
> 
> 
> What about improving oprofile then?  Unlike the vtune or perfoman people
> the oprofile authors have shown they actually are able to design sensible
> interfaces, and oprofile has broad plattform support over most support
> architectures.

Oprofile cannot be improved to provide stopwatch timing.
It is impossible because oprofile is sampling, not direct measurement.
Perfmon2, or anything which requires a system call to read a meter
[counter] of nanoseconds [per-thread virtualized cycle counter]
often adds unreasonably high overhead: hundreds of cycles or more,
instead of tens or less.  CPU manufacturers are making life
difficult for users of perfctr, by muddying the meaning of
their user-readable cycle counters (see x86 RDTSC) or by omitting
user-readable cycle counters entirely (whether in the name of lower cost,
reducing "side channel" system information leaks, or otherwise.)

--