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

[Nicholas Miell <nmiell@comcast.net>]

On Tue, 2005-11-29 at 23:43 +0100, Andi Kleen wrote:
> > 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.
> 
> There's no user space ABI change involved, at least not from
> the kernel side. Hardware is breaking some assumptions people
> made though (they actually never worked fully, but these days they
> break more clearly) and this is a best effort to adapt.

Yes there is, you're allowing userspace usage of RDPMC and you're
guaranteeing that PMC0 will always be a cycle counter. The RDPMC usage
is benign (assuming you make a note somewhere that future versions of
Linux might disable both RDPMC and RDTSC(P) to prevent timing-channel
attacks), but that "PMC0 is a cycle counter" guarantee will probably
come back to haunt you.

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

> The kernel will probably not disable RDTSC outright,
> but will make it clear in documentation that it's a bad
> idea to use directly and laugh at everybody who runs
> into problems with it.
> 
> oprofile usage might change slightly though, although only
> for a small subset of its users. There can't be very many
> of them using multiple performance counters anyways because
> at least in the last 0.9 release I tried it didn't even work.
> 
> > 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
> 
> Read the original messages in the thread. They explain it all.
> 
> > 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.
> 
> No, you got that totally wrong. Please read the RDTSCP specification again.

Whoops, thanks.

> > and
> > b) RDTSC isn't well defined.
> 
> It's well defined - but in a way that makes it useless for cycle
> measurements these days.
> 
> > 
> > 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.
> 
> Point, but i guess it is reasonable to assume that future x85 CPUs
> will have cycle counter perfctrs.  I cannot imagine anybody dropping
> such a basic facility.

I don't think that's a reasonable assumption at all.

The definition of all these performance events for the Opteron is hidden
away in a very terse chart in the BIOS/Kernel manual.

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.

My problem with this is basically that you are abusing something not
intended as a RDTSC-like interface to replace RDTSC, you're using a
scarce resource that could probably be put to better use to do it,
there's no guarantee that this abuse will continue to work in future
processor revisions, and this is a userspace-visible ABI change that
will have to be maintained indefinitely.

-- 
Nicholas Miell <nmiell@comcast.net>

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