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

Ray Bryant
2005-11-30T00:08:31Z

On Tuesday 29 November 2005 17:39, Andi Kleen wrote:
> > Well, if that's all you want them to use RDPMC 0 for, why not just make
> > PMCs programmable from userspace?
>
> First we need to have a cycle counter PMC anyways for the NMI watchdog.
> So it can as well be used for other purposes.
>

Yes, but that assumes having the NMI watchdog around is more important to you
than having 4 performance counters available. I'm perfectly willing to
have the NMI watchdog around by default, since it seems to be useful in most
cases. But if my measurement study needs 4 PMC's to do its job and I am
willing to forgo use of the NMI watchdog for that period of time, why
shouldn't I be allowed to do that? We have few enough PMCs anyway, I just
don't like the idea of giving one up forever. I'd much prefer to make that
decision myself rather than have it enforced by the OS. Let me make the
tradeoffs about which is the most valuable in my particular situation,
please.

Furthermore, if I know what I am doing, I can still make use of the RDTSC to
do timing. Yes, I have to pin the process to the current cpu and yes I have
to force the power state to a known setup, and oh yeah, we have to turn off
the halt in the idle loop, etc., etc., but after doing it works quite nicely,
thank you. And you've got a tremendous education problem to get people not
to use the RDTSC and lots of existing programs that have to be modified.

So, sure, allow RDPMC from ring 3. For people who want to use RDPMC and
performance counter 0 for timing, let them do that.

The real issue here is that there needs to be a defined kernel interface to
allow user programs to allocate and use PMCs and that is part of what this
whole discussion on the perfctr-devel mailing list has been about. Let's
get that defined and then if a user requests PMC0 and insists on using it,
then perhaps the NMI watchdog will simply have to go away until PMC0 is
available to the kernel again.

I'm also not sure what the performance tradeoff between RDTSC/P and RDPMC is
across processor implementations, now and future. That's something that
needs to be looked at.

> And using virtual performance counters adds a large cost the
> context switch for changing the MSRs around. An always running counter
> avoids this problem.
>
> -Andi

--
Ray Bryant
AMD Performance Labs Austin, Tx
512-602-0038 (o) 512-507-7807 (c)