The 'perf stat' output for a certain executable is shown below.

2,207,929,785,602 cpu-cycles # 1.098 GHz [58.33%]
955,083,725,303 instructions # 0.43 insns per cycle [58.33%]
412,816,464,977 cache-references # 205.308 M/sec [58.33%]
38,645,898,456 cache-misses # 9.362 % of all cache refs [58.33%]
4,692,761,524 branch-misses # 2.334 M/sec [58.33%]
0 ref-cycles # 0.000 K/sec [58.34%]
2010722.835480 cpu-clock (msec)
2010721.870420 task-clock (msec) # 1.000 CPUs utilized
214,190 page-faults # 0.107 K/sec
4,931 context-switches # 0.002 K/sec
1 cpu-migrations # 0.000 K/sec
214,190 minor-faults # 0.107 K/sec
0 major-faults # 0.000 K/sec
0 alignment-faults # 0.000 K/sec
0 emulation-faults # 0.000 K/sec
412,932,984,788 L1-dcache-loads # 205.366 M/sec [58.33%]
38,652,092,016 L1-dcache-load-misses # 9.36% of all L1-dcache hits [50.00%]
412,973,918,453 L1-dcache-stores # 205.386 M/sec [50.00%]
38,637,972,959 L1-dcache-store-misses # 19.216 M/sec [50.00%]
137,439,818,973 branch-loads # 68.353 M/sec [50.00%]
4,695,820,373 branch-load-misses # 2.335 M/sec [50.00%]

I would like to know what the percentage values shown on the rightmost column in some of the rows mean.
Thank you.

Dani AI

Generated

Short answer: the square-bracket numbers at the far right (e.g. [58.33%], [50.00%]) are not CPU usage or cache-miss rates — they show how much of the run time that particular hardware event was actually measured on the PMU. When perf has to time‑share the hardware counters (multiplexing) an event is only “running” part of the time; perf reports that fraction so the tool can scale the raw count back up. (stackoverflow.com)

That explains why the output contains two different-looking percentages: the inline percent after “#” (for example “9.362 % of all cache refs”) is a derived metric (miss-rate, ratio of one counter to another), while the bracketed percentage is the PMU measurement fraction (the multiplex percent). The CPU-utilization shown in the task-clock line (“# 1.000 CPUs utilized”) is a separate value and is the one that represents how many CPU cores were used. (brendangregg.com)

How the counts are adjusted: perf scales counts using the enabled/running times; conceptually final_count = raw_count * (time_enabled / time_running). The bracket value corresponds to the running/enabled fraction (expressed as a percent). If the percent is well under 100%, the printed counts are estimates (they were measured only part of the time and then scaled), so results can have blind spots. To avoid or reduce multiplexing, measure fewer events, put events that must be measured together in a group (curly braces), or run separate runs for different event sets. (perfwiki.github.io)

Examples (practical):

# measure two events together (prefer grouping so they aren't multiplexed)
perf stat -e '{cycles,instructions}' ./myprog

# many events (may get multiplexed)
perf stat -e cycles,instructions,cache-misses,branch-misses ./myprog

# print raw counts (no scaling); use with care
perf stat --no-scale -e cycles,instructions,cache-misses ./myprog

# repeat runs to see variability
perf stat -r 5 -e cycles,instructions ./myprog

Reference: perf wiki / perf stat docs for multiplexing and scaling, and perf_event_open definitions for time_enabled/time_running. (perfwiki.github.io)

(Note: this corrects ’s guess about CPU usage — the bracket is the PMU multiplex fraction; the inline “% of all …” is the cache/branch ratio.)

It depends. Some seem to indicate the percentage of the CPU that the process is using. Others will indicate what percentage of cache hits don't find the data needed in the cache and so require reloading the data from memory (ram). You might want to read the man page for perf-stat for more information.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.