1LIBPFM(3)                  Linux Programmer's Manual                 LIBPFM(3)
2
3
4

NAME

6       libpfm_intel_glm - support for Intel Goldmont core PMU
7

SYNOPSIS

9       #include <perfmon/pfmlib.h>
10
11       PMU name: glm
12       PMU desc: Intel Goldmont
13
14

DESCRIPTION

16       The  library  supports  the Intel Goldmont core PMU. It should be noted
17       that this PMU model only covers each core's  PMU  and  not  the  socket
18       level PMU.
19
20       On  Goldmont,  the  number of generic counters is 4. There is no Hyper‐
21       Threading support.  The pfm_get_pmu_info() function returns the maximum
22       number of generic counters in num_cntrs.
23
24

MODIFIERS

26       The following modifiers are supported on Intel Goldmont processors:
27
28       u      Measure  at  user level which includes privilege levels 1, 2, 3.
29              This corresponds to PFM_PLM3.  This is a boolean modifier.
30
31       k      Measure at kernel level which includes privilege level  0.  This
32              corresponds to PFM_PLM0.  This is a boolean modifier.
33
34       i      Invert  the  meaning  of  the  event. The counter will now count
35              cycles in which the event is not occurring. This  is  a  boolean
36              modifier
37
38       e      Enable  edge  detection,  i.e., count only when there is a state
39              transition from no occurrence of  the  event  to  at  least  one
40              occurrence.  This  modifier must be combined with a counter mask
41              modifier (m) with a value greater or equal to one.   This  is  a
42              boolean modifier.
43
44       c      Set  the  counter  mask value. The mask acts as a threshold. The
45              counter will count the number of cycles in which the  number  of
46              occurrences  of  the event is greater or equal to the threshold.
47              This is an integer modifier with values in the range [0:255].
48
49

OFFCORE_RESPONSE events

51       Intel Goldmont provides two offcore_response events.  They  are  called
52       OFFCORE_RESPONSE_0 and OFFCORE_RESPONSE_1.
53
54       Those  events  need special treatment in the performance monitoring in‐
55       frastructure because each event uses an extra register  to  store  some
56       settings.  Thus, in case multiple offcore_response events are monitored
57       simultaneously, the kernel needs to manage the sharing  of  that  extra
58       register.
59
60       The  offcore_response  events  are  exposed  as  normal  events  by the
61       library. The extra settings are exposed as regular umasks. The  library
62       takes  care  of  encoding the events according to the underlying kernel
63       interface.
64
65       On Intel Goldmont, the umasks are divided into 4  categories:  request,
66       supplier  and snoop and average latency. Offcore_response event has two
67       modes of operations: normal and average latency.  In  the  first  mode,
68       the two offcore_respnse events operate independently of each other. The
69       user must provide at least one umask for each  of  the  first  3  cate‐
70       gories:  request,  supplier,  snoop.  In  the second mode, the two off‐
71       core_response events are combined to compute  an  average  latency  per
72       request type.
73
74       For  the  normal  mode,  there  is  a special supplier (response) umask
75       called ANY_RESPONSE. When this umask is used then it overrides any sup‐
76       plier  and  snoop  umasks.  In  other  words,  users can specify either
77       ANY_RESPONSE OR any combinations of supplier + snoops. In case no  sup‐
78       plier   or   snoop   is   specified,  the  library  defaults  to  using
79       ANY_RESPONSE.
80
81       For instance, the following are valid event selections:
82
83       OFFCORE_RESPONSE_0:DMND_DATA_RD:ANY_RESPONSE
84
85       OFFCORE_RESPONSE_0:ANY_REQUEST
86
87       OFFCORE_RESPONSE_0:ANY_RFO:LLC_HITM:SNOOP_ANY
88
89
90       But the following are illegal:
91
92
93       OFFCORE_RESPONSE_0:ANY_RFO:LLC_HITM:ANY_RESPONSE
94
95       OFFCORE_RESPONSE_0:ANY_RFO:LLC_HITM:SNOOP_ANY:ANY_RESPONSE
96
97       In average latency  mode,  OFFCORE_RESPONSE_0  must  be  programmed  to
98       select  the  request types of interest, for instance, DMND_DATA_RD, and
99       the OUTSTANDING umask must be set  and  no  others.  the  library  will
100       enforce that restriction as soon as the OUTSTANDING umask is used. Then
101       OFFCORE_RESPONSE_1 must be set with the  same  request  types  and  the
102       ANY_RESPONSE  umask. It should be noted that the library encodes events
103       independently of each  other  and  therefore  cannot  verify  that  the
104       requests  are  matching  between  the  two  events.  Example of average
105       latency settings:
106
107       OFFCORE_RESPONSE_0:DMND_DATA_RD:OUTSTANDING+OFF‐
108       CORE_RESPONSE_1:DMND_DATA_RD:ANY_RESPONSE
109
110       OFFCORE_RESPONSE_0:ANY_REQUEST:OUTSTANDING+OFF‐
111       CORE_RESPONSE_1:ANY_REQUEST:ANY_RESPONSE
112
113       The average latency for the request(s)  is  obtained  by  dividing  the
114       counts  of  OFFCORE_RESPONSE_0  by the count of OFFCORE_RESPONSE_1. The
115       ratio is expressed in core cycles.
116
117

AUTHORS

119       Stephane Eranian <eranian@gmail.com>
120
121
122
123                                  July, 2016                         LIBPFM(3)