There are different ways to measure L3 cache misses and they vary with architecture. Therefore, let's focus on the cycles first. Are you measuring cycles on 1 core or on the complete CPU? PCM reports the cycles including turbo mode (in contrast to "reference cycles"). Is PAPI doing the same?

What kind of CPU are you using and how many threads is your workload using?

Kind regards
Thomas

Hi,

getCycles is returning the count for CPU_CLK_UNHALTED.THREAD event (which also accounts Turbo Boost as Thomas mentioned). Which underlying hardware eventdoes PAPI map to PAPI_TOT_CYC?

In PCM the mapping of getL3CacheMisses to HW event depends on processor/architecture type. What is your cpu model?

Are you measuring (aggregated) cyclesfor all cores or a particular core or for just your thread(s)when usingPAPI?
PCM can measure cycles/cache missesfor particular cores or sockets or the whole system. The scope of the measurement depends on what PCM state object you are using:CoreCounterState or SocketCounterState or SystemCounterState.

Best regards,
Roman

Hi VS,

a few more questions:

How do you run PCM: are you using the command line pcm.x and start your program from pcm.x to measure and outputthe metrics? If you use the command line pcm.x interface, you can post the output here to shed more light. Or did you instrument your program/function calls in the program using PCM API (retrieving SystemCounterState objects and calling getCycle methods on these objects) ?

Best regards,
Roman

Hello V S,
I have some questions about the results you are seeing.
The questions are kind of basic but need to be asked...

What workload are you running while you are taking the measurements?
The PAPI measurement (at 5.6e8 cycles) covers about 0.2 cpu seconds.
The PCM measurement (at1.29e9 cycles) covers about 0.46 cpu seconds.
If you are measuring a basically idle system then the 'unhalted cycles' can vary quite a bit depending on what random process is running.
Or if the cpus are halted, then the unhalted clockticks won't increment.
I would expect that, if you ran workload that kept all the CPUs busy for say, 10 seconds, then PAPI and PCM would agree within a percent or so.
Pat

Hi VS,

does Click/your workload include processing in Linux kernel module? You can see that if youobserve some"system time" in top or vmstat utility.

Does PAPI account clock cycles spent outside of your user thread (in kernel)? Intel PCM accounts every clock tickon the cores: no matter if it was system (ring0)or user cpu time (ring3).

--
Roman

Hi all, I have a similar problem and I came across this post from a google search. The problem I'm having is that the cycles reported by PCM and the cycles measured by a custom rdtsc code doesn't match each other. First of all, I make sure that threads are affinitized to certain cores. I do the rdtsc measurements on the same thread. The locations for rdtsc and PCM calls are at the same lines. I understand thatSystemCounterState reports among all the sockets/cores so I changed my code to useCoreCounterState. However the problem still persists where the cycles reported by PCM is less now. Number of cycles reported by rdtsc is about 12 billion and cycles reported by PCM is about 9 billion. I'm still curious why there is such a difference. Just to give more information, the machine I'm working with isIntel Xeon L5520 2.26Ghz with 2 sockets and each cpu has 4 cores with HT enabled. I'm only using 8 threads. Thanks in advance for the help, btw here is the code for rdtsc: unsigned long lo, hi; __asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi)); tick = (unsigned long long) hi << 32 | lo;

unsigned long lo, hi; __asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi)); tick = (unsigned long long) hi << 32 | lo;

Hello cagribal,
The rdtsc instruction returns the time stamp counter.
The time stamp counter (on the L5520 nehalem-based processor) continues counting when the cpu is halted.
The getCycle() routine uses the CPU_CLK_UNHALTED.THREAD event which stops counting when the cpu is halted.
This is probably the difference that you are seeing.
Pat

Hi,

the getCycles() function returns the CPU_CLK_UNHALTED.THREAD event count.It isthe number core clock cycles when signal on a specific core is running (not halted).

The counter does not advance in the following conditions:
- an ACPI C-state is other than C0 for normal operation
- HLT
- STPCLK+ pin is asserted
- being throttled by TM1
- during the frequency switching phase of a performance state transition

The getRefCycles() function returns the CPU_CLK_UNHALTED.REF event countwhichisthe number of reference clock cycles while clock signal on the core is running. The reference clock operates at a fixed frequency, irrespective of core frequency changes due to performance state transitions. Note that CPU_CLK_UNHALTED.THREAD can exceed the CPU_CLK_UNHALTED.REF event count if Turbo Boost kicks in.

Roman

one can find documentation for the PCM methods in Doxygen format in the cpucounters.h header. HTML documentation can be easily generated from it (the included doxygen project file iscalled "Doxyfile").