Re: [PATCH][3/7] perfctr-2.7.2 for 2.6.6-mm2: x86_64

[Andi Kleen <ak@muc.de>]

On Sat, May 15, 2004 at 04:44:13PM +0200, Mikael Pettersson wrote:
> On Sat, 15 May 2004 11:09:11 +0200, Andi Kleen wrote:
> >> entail; just look at the horrendous mess that is the P4 performance
> >> counter event selector.
> >
> >There is no way around that - there are kernel users (like the
> >nmi watchdog or oprofile) and kernel users cannot be made dependent 
> >on user space modules.
> 
> The NMI watchdog uses a simple static mapping. No problem there.

So how do you prevent your user applications from overwriting
the single perfctr the watchdog uses?

I actually wrote some monitoring applications that changed perfctrs
from user space in the past (using /dev/msr), but I always wanted
to get rid of the adhoc hacks I had to do to detect interaction with the 
watchdog and replace them with a real mechanism.

> User-space needs to know about it anyway. For instance, unless
> you understand the HW constraints, you may try to enable mutually
> exclusive events. Some events may be unconstrained, but you need
> to know about the constrained ones before you assign the
> unconstrained ones. And user-space must know the mapping anyway
> for the RDPMC instruction.

Sure, but it could still ask the kernel if it's available, no?

> 
> The kernel, in the case of both perfctr and oprofile, needs to be
> informed of the mapping, but it has no real reason to compute it
> itself -- especially not on a complex machine like the P4.

It needs some way to veto a mapping when the counter is already
used for something.

> We don't put an abstract floating-point module in the kernel,
> charging it with choosing x87, 3dnow!, or sse code, and
> performing register allocation, do we?

Bad analogy.  The kernel switches the FP state and each process
has its own and does not impact any other processes.

It would be needed if the kernel used e.g. XMM0 for something
without hiding it from the user (like the NMI watchdog does), but 
that's not the case.

-AndI