tools/perf/Documentation/cpu-and-latency-overheads.txt

Source file repositories/reference/linux-study-clean/tools/perf/Documentation/cpu-and-latency-overheads.txt

File Facts

System
Linux kernel
Corpus path
tools/perf/Documentation/cpu-and-latency-overheads.txt
Extension
.txt
Size
3722 bytes
Lines
86
Domain
Support Tooling And Documentation
Bucket
tools
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

CPU and latency overheads
-------------------------
There are two notions of time: wall-clock time and CPU time.
For a single-threaded program, or a program running on a single-core machine,
these notions are the same. However, for a multi-threaded/multi-process program
running on a multi-core machine, these notions are significantly different.
Each second of wall-clock time we have number-of-cores seconds of CPU time.
Perf can measure overhead for both of these times (shown in 'overhead' and
'latency' columns for CPU and wall-clock time correspondingly).

Optimizing CPU overhead is useful to improve 'throughput', while optimizing
latency overhead is useful to improve 'latency'. It's important to understand
which one is useful in a concrete situation at hand. For example, the former
may be useful to improve max throughput of a CI build server that runs on 100%
CPU utilization, while the latter may be useful to improve user-perceived
latency of a single interactive program build.
These overheads may be significantly different in some cases. For example,
consider a program that executes function 'foo' for 9 seconds with 1 thread,
and then executes function 'bar' for 1 second with 128 threads (consumes
128 seconds of CPU time). The CPU overhead is: 'foo' - 6.6%, 'bar' - 93.4%.
While the latency overhead is: 'foo' - 90%, 'bar' - 10%. If we try to optimize
running time of the program looking at the (wrong in this case) CPU overhead,
we would concentrate on the function 'bar', but it can yield only 10% running
time improvement at best.

By default, perf shows only CPU overhead. To show latency overhead, use
'perf record --latency' and 'perf report':

-----------------------------------
Overhead  Latency  Command
  93.88%   25.79%  cc1
   1.90%   39.87%  gzip
   0.99%   10.16%  dpkg-deb
   0.57%    1.00%  as
   0.40%    0.46%  sh
-----------------------------------

To sort by latency overhead, use 'perf report --latency':

-----------------------------------
Latency  Overhead  Command
 39.87%     1.90%  gzip
 25.79%    93.88%  cc1
 10.16%     0.99%  dpkg-deb
  4.17%     0.29%  git
  2.81%     0.11%  objtool
-----------------------------------

To get insight into the difference between the overheads, you may check
parallelization histogram with '--sort=latency,parallelism,comm,symbol --hierarchy'
flags. It shows fraction of (wall-clock) time the workload utilizes different
numbers of cores ('Parallelism' column). For example, in the following case
the workload utilizes only 1 core most of the time, but also has some
highly-parallel phases, which explains significant difference between
CPU and wall-clock overheads:

-----------------------------------
  Latency  Overhead     Parallelism / Command / Symbol
+  56.98%     2.29%     1
+  16.94%     1.36%     2
+   4.00%    20.13%     125
+   3.66%    18.25%     124
+   3.48%    17.66%     126
+   3.26%     0.39%     3
+   2.61%    12.93%     123
-----------------------------------

By expanding corresponding lines, you may see what commands/functions run
at the given parallelism level:

Annotation

Implementation Notes