blob: 633bcee7dc8554abc832400f5cd1d4400ed95ef0 (
plain) (
tree)
|
|
.. SPDX-License-Identifier: GPL-2.0
.. _imc:
===================================
IMC (In-Memory Collection Counters)
===================================
Anju T Sudhakar, 10 May 2019
.. contents::
:depth: 3
Basic overview
==============
IMC (In-Memory collection counters) is a hardware monitoring facility that
collects large numbers of hardware performance events at Nest level (these are
on-chip but off-core), Core level and Thread level.
The Nest PMU counters are handled by a Nest IMC microcode which runs in the OCC
(On-Chip Controller) complex. The microcode collects the counter data and moves
the nest IMC counter data to memory.
The Core and Thread IMC PMU counters are handled in the core. Core level PMU
counters give us the IMC counters' data per core and thread level PMU counters
give us the IMC counters' data per CPU thread.
OPAL obtains the IMC PMU and supported events information from the IMC Catalog
and passes on to the kernel via the device tree. The event's information
contains:
- Event name
- Event Offset
- Event description
and possibly also:
- Event scale
- Event unit
Some PMUs may have a common scale and unit values for all their supported
events. For those cases, the scale and unit properties for those events must be
inherited from the PMU.
The event offset in the memory is where the counter data gets accumulated.
IMC catalog is available at:
https://github.com/open-power/ima-catalog
The kernel discovers the IMC counters information in the device tree at the
`imc-counters` device node which has a compatible field
`ibm,opal-in-memory-counters`. From the device tree, the kernel parses the PMUs
and their event's information and register the PMU and its attributes in the
kernel.
IMC example usage
=================
.. code-block:: sh
# perf list
[...]
nest_mcs01/PM_MCS01_64B_RD_DISP_PORT01/ [Kernel PMU event]
nest_mcs01/PM_MCS01_64B_RD_DISP_PORT23/ [Kernel PMU event]
[...]
core_imc/CPM_0THRD_NON_IDLE_PCYC/ [Kernel PMU event]
core_imc/CPM_1THRD_NON_IDLE_INST/ [Kernel PMU event]
[...]
thread_imc/CPM_0THRD_NON_IDLE_PCYC/ [Kernel PMU event]
thread_imc/CPM_1THRD_NON_IDLE_INST/ [Kernel PMU event]
To see per chip data for nest_mcs0/PM_MCS_DOWN_128B_DATA_XFER_MC0/:
.. code-block:: sh
# ./perf stat -e "nest_mcs01/PM_MCS01_64B_WR_DISP_PORT01/" -a --per-socket
To see non-idle instructions for core 0:
.. code-block:: sh
# ./perf stat -e "core_imc/CPM_NON_IDLE_INST/" -C 0 -I 1000
To see non-idle instructions for a "make":
.. code-block:: sh
# ./perf stat -e "thread_imc/CPM_NON_IDLE_PCYC/" make
IMC Trace-mode
===============
POWER9 supports two modes for IMC which are the Accumulation mode and Trace
mode. In Accumulation mode, event counts are accumulated in system Memory.
Hypervisor then reads the posted counts periodically or when requested. In IMC
Trace mode, the 64 bit trace SCOM value is initialized with the event
information. The CPMCxSEL and CPMC_LOAD in the trace SCOM, specifies the event
to be monitored and the sampling duration. On each overflow in the CPMCxSEL,
hardware snapshots the program counter along with event counts and writes into
memory pointed by LDBAR.
LDBAR is a 64 bit special purpose per thread register, it has bits to indicate
whether hardware is configured for accumulation or trace mode.
LDBAR Register Layout
---------------------
+-------+----------------------+
| 0 | Enable/Disable |
+-------+----------------------+
| 1 | 0: Accumulation Mode |
| +----------------------+
| | 1: Trace Mode |
+-------+----------------------+
| 2:3 | Reserved |
+-------+----------------------+
| 4-6 | PB scope |
+-------+----------------------+
| 7 | Reserved |
+-------+----------------------+
| 8:50 | Counter Address |
+-------+----------------------+
| 51:63 | Reserved |
+-------+----------------------+
TRACE_IMC_SCOM bit representation
---------------------------------
+-------+------------+
| 0:1 | SAMPSEL |
+-------+------------+
| 2:33 | CPMC_LOAD |
+-------+------------+
| 34:40 | CPMC1SEL |
+-------+------------+
| 41:47 | CPMC2SEL |
+-------+------------+
| 48:50 | BUFFERSIZE |
+-------+------------+
| 51:63 | RESERVED |
+-------+------------+
CPMC_LOAD contains the sampling duration. SAMPSEL and CPMCxSEL determines the
event to count. BUFFERSIZE indicates the memory range. On each overflow,
hardware snapshots the program counter along with event counts and updates the
memory and reloads the CMPC_LOAD value for the next sampling duration. IMC
hardware does not support exceptions, so it quietly wraps around if memory
buffer reaches the end.
*Currently the event monitored for trace-mode is fixed as cycle.*
Trace IMC example usage
=======================
.. code-block:: sh
# perf list
[....]
trace_imc/trace_cycles/ [Kernel PMU event]
To record an application/process with trace-imc event:
.. code-block:: sh
# perf record -e trace_imc/trace_cycles/ yes > /dev/null
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.012 MB perf.data (21 samples) ]
The `perf.data` generated, can be read using perf report.
Benefits of using IMC trace-mode
================================
PMI (Performance Monitoring Interrupts) interrupt handling is avoided, since IMC
trace mode snapshots the program counter and updates to the memory. And this
also provide a way for the operating system to do instruction sampling in real
time without PMI processing overhead.
Performance data using `perf top` with and without trace-imc event.
PMI interrupts count when `perf top` command is executed without trace-imc event.
.. code-block:: sh
# grep PMI /proc/interrupts
PMI: 0 0 0 0 Performance monitoring interrupts
# ./perf top
...
# grep PMI /proc/interrupts
PMI: 39735 8710 17338 17801 Performance monitoring interrupts
# ./perf top -e trace_imc/trace_cycles/
...
# grep PMI /proc/interrupts
PMI: 39735 8710 17338 17801 Performance monitoring interrupts
That is, the PMI interrupt counts do not increment when using the `trace_imc` event.
|
