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

[Nicholas Miell <nmiell@comcast.net>]

On Wed, 2005-11-30 at 00:17 +0100, Andi Kleen wrote:
> On Tue, Nov 29, 2005 at 03:02:18PM -0800, Nicholas Miell wrote:
> > On Tue, 2005-11-29 at 23:43 +0100, Andi Kleen wrote:
> > > To give an bad analogy RDTSC usage in the last years is
> > > like explicit spinning wait loops for delays in the earlier
> > > times. They tended to work on some subset of computers,
> > > but were always bad and caused problems and people eventually learned
> > > it was better to use operating system services for this.
> > 
> > And you are now suggesting people should use RDPMC instead of OS
> > services?
> 
> For any kind of timers they should use the OS service 
> (gettimeofday/clock_gettime). The OS will go to extraordinary
> means to make it as fast as possible, but when it's slow
> then because it's not possible to do it faster accurately
> (that's the case right now modulo one possible optimization)
> 
> For cycle counting where they previously used RDTSC they should
> use RDPMC 0 now.

Well, if that's all you want them to use RDPMC 0 for, why not just make
PMCs programmable from userspace?

> > That chart contains incompatible variations for pre-B, B, and C revision
> > processors and (among other strange things) includes instructions for
> > the monitoring of segment register loads to the HS register.
> > 
> > Everything is telling me that this is not something AMD intends to keep
> > stable and it isn't even something they're interested in documenting
> > very well at all.
> 
> There are obscure performance counters and then there are basic
> fundamental performance counters. That particular counter hasn't
> changed since the K7 days (and K6 didn't have performance counters) 

Sounds like the gamblers fallacy to me, but I'll take your word for it
for now.

-- 
Nicholas Miell <nmiell@comcast.net>