# libpfm_intel_knl

## NAME



           libpfm_intel_knl - support for Intel Knights Landing core PMU
    


## SYNOPSIS



           **#include <perfmon/pfmlib.h>**
    
           **PMU name: knl**
           **PMU desc: Intel Knights Landing**
    


## DESCRIPTION



           The library supports the Intel Knights Landing core PMU. It should
           be noted that this PMU model only covers each core's PMU and not
           the socket level PMU.
    
           On Knights Landing, the number of generic counters is 4. There is
           4-way 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 Knights Landing
           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].
    
           **t** Measure on any of the 4 hyper-threads at the same time
                  assuming hyper-threading is enabled. This is a boolean
                  modifier.  This modifier is only available on fixed
                  counters (unhalted_reference_cycles, instructions_retired,
                  unhalted_core_cycles).  Depending on the underlying kernel
                  interface, the event may be programmed on a fixed counter
                  or a generic counter, except for unhalted_reference_cycles,
                  in which case, this modifier may be ignored or rejected.
    


## OFFCORE_RESPONSE events



           Intel Knights Landing 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 Knights Landing, 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:DDR_NEAR**
    
           But the following is illegal:
    
           **OFFCORE_RESPONSE_0:ANY_RFO:DDR_NEAR: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.
    


* * *