Re: [patch 0/3] [Announcement] Performance Counters for Linux

[Paul Mackerras <paulus@samba.org>]

Ingo Molnar writes:
> 
> * Paul Mackerras <paulus@samba.org> wrote:
[snip]
> > One thing that this sort of thing can't do is to get values from 
> > multiple counters that correlate with each other.  For instance, we 
> > would often want to count, say, L2 cache misses and instructions 
> > completed at the same time, and be able to read both counters at very 
> > close to the same time, so that we can measure average L2 cache misses 
> > per instruction completed, which is useful.
> 
> This can be done in a very natural way with our abstraction, and the 
> "hello.c" example happens to do exactly that:

Has hello.c been posted?  I can't find it in any of the posts from you
or Thomas.  Am I just being blind? :)

>   aldebaran:~/perf-counter-test> ./hello
>   doing perf_counter_open() call:
>   counter[0]... fd: 3.
>   counter[1]... fd: 4.
>   counter[0] delta: 10866 cycles
>   counter[1] delta: 414 cycles
>   counter[0] delta: 23640 cycles
>   counter[1] delta: 3673 cycles
>   counter[0] delta: 28225 cycles
>   counter[1] delta: 3695 cycles
> 
> This counts cycles executed and instructions executed, and reads the two 
> counters out at the same time.

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.

If the monitored task is not stopped, then the interval between the
two reads will be sufficient to render the results useless -
particularly since the monitoring task could get preempted for an
arbitrary length of time between the two reads.  But even if it
doesn't, the hundreds of cycles between the two reads will introduce
considerable imprecision in the results.

There really is value in being able to read all the counters you're
using in one system call.

Paul.