EMR: CLOCKTICKS changes significantly when using P2P_CRD_OCCUPANCY #332
Description
Hi,
I am studying peer-to-peer (P2P) traffic on an Intel Xeon Scalable Processor (Gold 6526Y). In the background, an application triggers P2P data transfers from IIO_8 to IIO_1 (within the same socket, S1). I am trying to analyze P2P credits.
From the document, I found 2 counters:
UNC_M2P_P2P_CRD_OCCUPANCY.LOCAL_NCB (on page 275):
CLOCKTICKS (on page 282. I did not find this counter listed in emeraldrapids_uncore_experimental.json):
The workload remains unchanged, but when I run the two commands below (uncore_m2pcie_1 is the receiver side), the reported number of clock ticks differs:
~$ sudo perf stat -a --per-socket -e 'uncore_m2pcie_1/event=0x1/' -e 'uncore_m2pcie_1/event=0x14,umask=0x01/' -- sleep 1
Performance counter stats for 'system wide':
S0 1 4,555 uncore_m2pcie_1/event=0x1/
S0 1 0 uncore_m2pcie_1/event=0x14,umask=0x01/
S1 1 3,960 uncore_m2pcie_1/event=0x1/
S1 1 185,547,916,227 uncore_m2pcie_1/event=0x14,umask=0x01/
1.000726843 seconds time elapsed
~$ sudo perf stat -a --per-socket -e 'uncore_m2pcie_1/event=0x1/' -- sleep 1
Performance counter stats for 'system wide':
S0 1 2,501,812,075 uncore_m2pcie_1/event=0x1/
S1 1 2,501,845,625 uncore_m2pcie_1/event=0x1/
1.000719858 seconds time elapsedThe same issue happens on the sender side, when using CLOCKTICKS and UNC_M2P_TxC_CREDITS.PRQ simultaneously.
~$ sudo perf stat -a --per-socket -e 'uncore_m2pcie_8/event=0x1/' -- sleep 1
Performance counter stats for 'system wide':
S0 1 2,501,877,387 uncore_m2pcie_8/event=0x1/
S1 1 2,501,879,920 uncore_m2pcie_8/event=0x1/
1.000734614 seconds time elapsed
~$ sudo perf stat -a --per-socket -e 'uncore_m2pcie_8/event=0x1/' -e 'uncore_m2pcie_8/event=0x2d,umask=0x01/' -- sleep 1
Performance counter stats for 'system wide':
S0 1 5,345 uncore_m2pcie_8/event=0x1/
S0 1 2,501,815,830 uncore_m2pcie_8/event=0x2d,umask=0x01/
S1 1 4,688 uncore_m2pcie_8/event=0x1/
S1 1 1,247,844,120 uncore_m2pcie_8/event=0x2d,umask=0x01/
1.000703356 seconds time elapsedFrom my understanding, CLOCKTICKS shows the number of clock cycles during the monitoring interval. I don't understand why they vary this significantly.