What is the difference between hardware and software perf events?

Hardware events such as cycles and instructions are read from the CPU's Performance Monitoring Unit and are limited by the number of physical counters. Software events such as context-switches and page-faults are maintained by the kernel and have no counter limit.

How do I list all events available on my system?

Run perf list to print every supported event, grouped by hardware, software, cache, tracepoint and PMU-specific categories. Add a substring like perf list cache to filter the output to matching event names.

What does IPC mean in perf output?

IPC is instructions per cycle, computed as instructions divided by cpu-cycles. It indicates how much useful work the CPU does each cycle; a low IPC often signals stalls from cache misses, branch mispredictions or memory latency.

How do I sample a specific event with perf record?

Use perf record -e EVENT ./program, for example perf record -e cache-misses ./app. Use -g to capture call graphs and then perf report to browse the collected samples by function and symbol.

Why do some hardware events show or get multiplexed?

CPUs have a limited number of physical counters. When you request more events than counters, the kernel time-multiplexes them and scales the results, which adds estimation error. Reduce the number of simultaneous events for exact counts.

What is the Linux perf Events Reference?

Reference for Linux perf stat and record event names covering hardware counters, software events, cache events and tracepoints. Find the right event symbol and what it measures. It runs free in your browser on Gera Tools, with nothing uploaded.

Linux perf Events Reference

Name: Linux perf Events Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Linux perf events reference

The perf tool reads CPU performance counters and kernel statistics to profile programs. Each measurement is named by an event: a symbol like cycles, cache-misses, or sched:sched_switch that you pass to perf stat or perf record. This reference lists the common events, the category they belong to, and what each one actually measures.

Filter the list by name or category to find the right symbol, then run perf stat -e EVENT ./yourprogram to count it.

How it works

Hardware events come from the CPU’s Performance Monitoring Unit (PMU), a small set of programmable counters that increment on micro-architectural occurrences such as retired instructions or last-level-cache misses. Because there are only a handful of physical counters, requesting many events forces the kernel to multiplex them in time and scale the results.

Software events are bookkeeping counters the kernel maintains directly — context switches, page faults, CPU migrations — so they are exact and unlimited. Cache events use a generic encoding of {L1D, LLC, ...} x {load, store} x {access, miss}. Tracepoints are static instrumentation points in kernel subsystems (block:, sched:, syscalls:) that fire on specific events. Symbolic names map to raw PMU codes; you can also specify a raw event with r<hex>.

Tips and examples

Measure IPC and cache behavior for a command:

perf stat -e cycles,instructions,cache-references,cache-misses ./app

Sample where cache misses happen and view by function:

perf record -e cache-misses -g ./app
perf report

Counting is low-overhead; sampling (record) is higher overhead but shows where. Use perf list to confirm which events your specific CPU supports — names vary across microarchitectures, and PMU-specific events appear as cpu/event=.../.

Reading and interpreting perf stat output

Running perf stat ./app prints a table after the program exits. The key columns are the raw count and a ratio. Two ratios to focus on first:

IPC (instructions per cycle). A value near or above 1.0 means the CPU is doing useful work most of the time. A value below 0.5 typically signals memory stalls — the CPU is waiting for data that is not in cache. Targeting IPC improvements usually means reducing cache misses or restructuring data access patterns.

Cache miss rate. The ratio cache-misses / cache-references tells you what fraction of memory requests missed the last-level cache. A high miss rate (above roughly 10–15%) is a strong signal that your working set does not fit in cache or that access patterns are non-sequential.

Example output to interpret:

1,200,000,000   cycles
  950,000,000   instructions        #  0.79  insn per cycle
    8,000,000   cache-references
    2,400,000   cache-misses        # 30.00% of cache refs

Here IPC of 0.79 and a 30% miss rate together point strongly at a memory-bound hotspot worth investigating with perf record.

Choosing between perf stat and perf record

Use case	Tool	Command pattern
Whole-program summary counts	`perf stat`	`perf stat -e events ./app`
Find which function causes misses	`perf record` + `perf report`	`perf record -e cache-misses -g ./app`
Live per-process counter stream	`perf top`	`perf top -e cache-misses`
System-wide scheduler tracing	`perf sched record`	`perf sched record sleep 5`

Counter multiplexing and estimation error

When you request more hardware events than the CPU has physical counters — typically 4 to 8 programmable counters per core — the kernel rotates which events are active. Each counter is therefore counting only part of the time, and the kernel scales the result proportionally. The scaled annotation in perf stat output marks multiplexed values. To get exact counts, limit your -e list to the number of physical counters your CPU exposes, which you can check with perf list or cat /proc/cpuinfo.