Re: [Perfctr-devel] Re: Enabling RDPMC in user space by default

[Nicholas Miell <nmiell@comcast.net>]

On Tue, 2005-11-29 at 22:52 +0100, Andi Kleen wrote:
> On Tue, Nov 29, 2005 at 01:43:11PM -0800, Nicholas Miell wrote:
> > On Tue, 2005-11-29 at 19:13 +0100, Andi Kleen wrote:
> > > > Where did you see that PMC0 (PERSEL0/PERFCTR0) can only be programmed
> > > > to count cpu cycles (i.e. cpu_clk_unhalted)? As far as I can tell from
> > > > the documentation, the 4 counters are symetrical and can measure
> > > > any event that the processor offers.
> > > 
> > > Linux NMI watchdog does that.
> > > 
> > > All other perfctr users are supposed to keep their fingers away 
> > > from the watchdog (it looks like oprofile doesn't but not for much
> > > longer ...) 
> > 
> > Why? Hardcoding PMC 0 to be a cycle counter seems to be a waste of a
> > perfectly usable performance counter. What if I want to profile four
> > things, none of them requiring a cycle count?
> 
> You won't then anymore. Providing a full replacement for RDTSC is 
> more important.
> 

I think you really need to come up with a better justification than "I
think this will be useful" for a permanent user-space ABI change.

What problem are you trying to solve, why is that a problem, how does
making PMC0 always be a cycle counter solve that, what makes you think
that future CPUs will have the same type of cycle counter that behaves
the same way as the current cycle counters, etc.

AFAICT, the problem you're trying to solve is two-fold:

a) RDTSC is serializing and RDPMC isn't.

Which is nicely solved by RDTSCP.

and
b) RDTSC isn't well defined.

Well, RDPMC isn't defined at all. You're assuming that future processor
revisions will have the same or substantially similar PerfCtrs as
current processors, and nothing guarantees that at all.

-- 
Nicholas Miell <nmiell@comcast.net>