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

["Bryan O'Sullivan" <bos@serpentine.com>]

On Sat, 2004-05-15 at 02:09, Andi Kleen wrote:

> > That's currently handled in user space, by PAPI (which sits on top of
> > perfctr).  One reason *not* to do it in the kernel is the bloat it would
> 
> That's clearly the wrong place to do it.

I can see both sides.  The perfctr driver already sanity-checks the
event selectors to make sure they're not set to anything malicious; this
is the very least it must do.

The next step up from that is allocating real performance counters
properly, but this requires quite a bit of work.  For example, you need
to know what the asymmetries in a particular CPU's counters are, so you
can tell which counter can handle the events being requested - this
varies from perfectly symmetrical (K7 and K8) through slightly odd (P3
and PM) to completely insane (P4).

After that, perhaps you start thinking about abstracting the notions of
what you're counting.  Different CPUs provide radically different ways
of counting roughly the same thing.  The event selectors for counting
instructions retired differ between AMD and P3, and between P3 and P4,
but they can all count this kind of event.  More primitive CPUs can't.

Beyond that, it is possible - and in some cases desirable - to, for
example, time-slice the real performance counters so that you could get
a somewhat representative sample of everything you wanted, assuming the
CPU could count it in the first place.  The Irix kernel does this.

Where would you draw the line?

Oh, I forgot to mention IA64 and SPARC64's incompatible performance
counter APIs :-)

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

There's no kernel-to-user dependency.

	<b