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

[Ray Bryant]

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)

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