Re: [Perfctr-devel] A question regarding the uncore and fixed counter event
Brought to you by:
mikpe
From: Mikael P. <mi...@it...> - 2011-10-08 12:45:10
|
Jia Rao writes: > Hi Mikael, > > Thanks for your reply. It was very helpful. > > I checked the code in example/global/global.c. Every interval, the program > will issue gperfctr_read() which calls the kernel-level function > perfctr_cpu_sample() to update the pmc values. > It seems that only a-counter (accumulative) counter values are updated in > perfctr_cpu_sample(). Are the fixed function counters considered as > i-counters(interrupt) only ? (please don't top-post in Linux-related mailing lists) (and please don't trim cc: lists, I added perfctr-devel back) Fixed-function counters can be used in interrupt-on-overflow mode just fine, but only in the virtual per-thread counters API (see examples/self/ and examples/signal/). The driver for global-mode counters only allows plain accumulation-mode counters, which is why examples/global/ only considers accumulation-mode counters. > As for the virtual pmcs, what I understand is that if I use 0x40000000 > (IA32_FIXED_CTR0: address 309H), the 5th virtual pmc will be used (I have 4 > general purpose pmcs in Intel westmere). Is it correct ? No, there is no such restriction. You can make virtual counter 0 a fixed-function counter and virtual counter 1 a programmed-event counter, by setting up pmc_map[] and evntsel[] appropriately. The only restrictions on the virtual counter indices are that: (a) they're consecutive from 0 to n-1, and (b) the accumulation-mode counters come first, followed by the interrupt-mode counters. Before you invest too much into perfctr, can I assume you've looked into the perf_events stuff that's in 2.6.32 and newer kernels? I know some perfctr users have expressed disappointment in perf_events (mostly related to higher overheads and a more complex usage model), but as perf_events is "standard" and perfctr is not (and never will be), it should be used by default unless you have a very good reason not to. And if you use PAPI you shouldn't have to care which low-level mechanism is in place. |