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

[Paul Mackerras]

Ingo Molnar writes:

> * Paul Mackerras <paulus@xxxxxxxxx> 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.

Can I ask - and this is a real question, I'm not being sarcastic - is
that statement made with substantial serious experience in performance
analysis behind it, or is it just an intuition?

I will happily admit that I am not a great expert on performance
analysis with years of experience.  But I have taken a bit of a look
at what people with that sort of experience do, and I don't think they
would agree with your "doesn't matter" statement.

> Such kind of 'group system call facility' has been suggested several 
> times in the past - but ... never got anywhere because system calls are 
> cheap enough, it really does not count in practice.
> 
> It could be implemented, and note that because our code uses a proper 
> Linux file descriptor abstraction, such a sys_read_fds() facility would 
> help _other_ applications as well, not just performance counters.
> 
> But it brings complications: demultiplexing of error conditions on 
> individual counters is a real pain with any compound abstraction. We very 
> consciously went with the 'one fd, one object, one counter' design.

And I think that is the fundamental flaw.  On the machines I am
familiar with, the performance counters as not separate things that
can individually and independently be assigned to count one thing or
another.

Rather, what the hardware provides is ONE performance monitor unit,
which the OS can context-switch between tasks.  The performance
monitor unit has several counters that can be assigned (within limits)
to count various aspects of the performance of the code being
executed.  That is why, for instance, if you ask for the counters to
be frozen when one of them overflows, they all get frozen at that
point.

And that's how the hardware is designed because that's how the people
that do performance analysis want to do their measurements.  This idea
of splitting things up into separate counters that look independent
but aren't is just going to cause unnecessary complications and
difficulties.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/