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

From: Nicholas Miell
Date: Tue Nov 29 2005 - 18:29:07 EST


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@xxxxxxxxxxx>

-
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/