Messages in this thread | | | Subject | Re: [PATCH][3/7] perfctr-2.7.2 for 2.6.6-mm2: x86_64 | From | Bryan O'Sullivan <> | Date | Sat, 15 May 2004 21:15:54 -0700 |
| |
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
- 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/
| |