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

[Paul Mackerras <paulus@samba.org>]

Paul Mundt writes:

> On Fri, Dec 05, 2008 at 12:08:14PM -0800, David Miller wrote:
> > From: Andi Kleen <andi@firstfloor.org>
> > Date: Fri, 05 Dec 2008 13:39:43 +0100
> > 
> > > Given these are more obscure features, but not being able to fit
> > > them easily into your model from the start isn't a very promising sign
> > > for the long term extensibility of the design.
> > 
> > Another thing I'm interested in is if this new stuff will work with
> > performance counters that lack an overflow interrupt.
> > 
> > We have several chips that are like this, and perfmon supported that
> > on the kernel side, and also provided overflow emulation for such
> > hardware in userspace (where such complexity belongs).
> 
> There doesn't seem to have been any reply to this point unfortunately,
> and it is something I am also wondering about.
> 
> The sh perf counters were not designed with overflowing in mind, they are
> split in to a pair of 48-bit or 64-bit counters that simply keep running.
> Any write simply clears the value and the counter starts over. They are
> simply counters only, and generate no events whatsoever.
> 
> Oprofile has been a pretty bad fit for them, and while I'm slightly more
> optimistic about perfmon, I'm rather less enthusiastic about yet another
> peformance counter implementation that I am unable to make any use of. 

This is the sampling vs. counting distinction again, and it sounds
like these counters were designed for counting but not sampling.  If
Ingo and Thomas extend their infrastructure to provide good support
for counting as well as sampling, then you should hopefully be able to
use them for counting, at least.

On POWER6 we have a somewhat similar situation with two out of the six
available counters.  These two counters are fixed function (they
always count cycles and instructions completed) and don't generate
interrupts.  Furthermore, they are only 32 bits wide.  So I definitely
agree we need support for counters that don't interrupt.

Paul.