# libpfm_intel_glm

## NAME



           libpfm_intel_glm - support for Intel Goldmont core PMU
    


## SYNOPSIS



           **#include <perfmon/pfmlib.h>**
    
           **PMU name: glm**
           **PMU desc: Intel Goldmont**
    


## DESCRIPTION



           The library supports the Intel Goldmont core PMU. It should be
           noted that this PMU model only covers each core's PMU and not the
           socket level PMU.
    
           On Goldmont, the number of generic counters is 4. There is no
           HyperThreading support.  The **pfm_get_pmu_info()** function returns
           the maximum number of generic counters in **num_cntrs.**
    


## MODIFIERS



           The following modifiers are supported on Intel Goldmont
           processors:
    
           **u** Measure at user level which includes privilege levels 1, 2,
                  3. This corresponds to **PFM_PLM3**.  This is a boolean
                  modifier.
    
           **k** Measure at kernel level which includes privilege level 0.
                  This corresponds to **PFM_PLM0**.  This is a boolean modifier.
    
           **i** Invert the meaning of the event. The counter will now count
                  cycles in which the event is **not** occurring. This is a
                  boolean modifier
    
           **e** Enable edge detection, i.e., count only when there is a
                  state transition from no occurrence of the event to at
                  least one occurrence. This modifier must be combined with a
                  counter mask modifier (m) with a value greater or equal to
                  one.  This is a boolean modifier.
    
           **c** Set the counter mask value. The mask acts as a threshold.
                  The counter will count the number of cycles in which the
                  number of occurrences of the event is greater or equal to
                  the threshold. This is an integer modifier with values in
                  the range [0:255].
    


## OFFCORE_RESPONSE events



           Intel Goldmont provides two offcore_response events. They are
           called OFFCORE_RESPONSE_0 and OFFCORE_RESPONSE_1.
    
           Those events need special treatment in the performance monitoring
           infrastructure because each event uses an extra register to store
           some settings. Thus, in case multiple offcore_response events are
           monitored simultaneously, the kernel needs to manage the sharing
           of that extra register.
    
           The offcore_response events are exposed as normal events by the
           library. The extra settings are exposed as regular umasks. The
           library takes care of encoding the events according to the
           underlying kernel interface.
    
           On Intel Goldmont, the umasks are divided into 4 categories:
           request, supplier and snoop and average latency. Offcore_response
           event has two modes of operations: normal and average latency.  In
           the first mode, the two offcore_respnse events operate
           independently of each other. The user must provide at least one
           umask for each of the first 3 categories: request, supplier,
           snoop. In the second mode, the two offcore_response events are
           combined to compute an average latency per request type.
    
           For the normal mode, there is a special supplier (response) umask
           called **ANY_RESPONSE**. When this umask is used then it overrides any
           supplier and snoop umasks. In other words, users can specify
           either **ANY_RESPONSE OR** any combinations of supplier + snoops. In
           case no supplier or snoop is specified, the library defaults to
           using **ANY_RESPONSE**.
    
           For instance, the following are valid event selections:
    
           **OFFCORE_RESPONSE_0:DMND_DATA_RD:ANY_RESPONSE**
    
           **OFFCORE_RESPONSE_0:ANY_REQUEST**
    
           **OFFCORE_RESPONSE_0:ANY_RFO:LLC_HITM:SNOOP_ANY**
    
           But the following are illegal:
    
           **OFFCORE_RESPONSE_0:ANY_RFO:LLC_HITM:ANY_RESPONSE**
    
           **OFFCORE_RESPONSE_0:ANY_RFO:LLC_HITM:SNOOP_ANY:ANY_RESPONSE**
    
           In average latency mode, **OFFCORE_RESPONSE_0** must be programmed to
           select the request types of interest, for instance, **DMND_DATA_RD** ,
           and the **OUTSTANDING** umask must be set and no others. the library
           will enforce that restriction as soon as the **OUTSTANDING** umask is
           used. Then **OFFCORE_RESPONSE_1** must be set with the same request
           types and the **ANY_RESPONSE** umask. It should be noted that the
           library encodes events independently of each other and therefore
           cannot verify that the requests are matching between the two
           events.  Example of average latency settings:
    
           **OFFCORE_RESPONSE_0:DMND_DATA_RD:OUTSTANDING+OFFCORE_RESPONSE_1:DMND_DATA_RD:ANY_RESPONSE**
    
           **OFFCORE_RESPONSE_0:ANY_REQUEST:OUTSTANDING+OFFCORE_RESPONSE_1:ANY_REQUEST:ANY_RESPONSE**
    
           The average latency for the request(s) is obtained by dividing the
           counts of **OFFCORE_RESPONSE_0** by the count of **OFFCORE_RESPONSE_1**.
           The ratio is expressed in core cycles.
    


* * *