PERF-INJECT(1)

✨ NAME ✨

okay bestie, welcome to the perf-inject page from the perf manual, section 1 πŸ’… β€” this one is literally a filter that augments your events stream with extra info, and it's kinda iconic.

πŸ¦‹ SYNOPSIS πŸ¦‹

perf inject <options>

πŸ’– DESCRIPTION πŸ’–

So perf-inject reads a perf record event stream and repipes it to stdout, no cap. And at literally any point, the processing code can inject other events into that stream β€” for example, build-ids (the -b option) get read and injected as needed into the event stream. Slay.

Build-ids are just the first user of perf-inject β€” potentially anything that needs userspace processing to augment the event stream with additional information could make use of this facility. It's giving main character energy for extensibility, fr fr.


🌸 OPTIONS 🌸

  • -b, --build-ids β€” inject build-ids of DSOs hit by samples into the output stream. The catch: it has to process all the SAMPLE records to find those DSOs. lowkey thorough.
  • --buildid-all β€” inject build-ids of all DSOs into the output stream regardless of hits, and skip SAMPLE processing. zero thoughts, just vibes.
  • --known-build-ids= β€” override build-ids to inject using these comma-separated pairs of build-id and path. It also understands file://filename to read these pairs from a file, which you can generate with perf buildid-list. iykyk.
  • -v, --verbose β€” be more verbose.
  • -i, --input= β€” input file name. (default: stdin)
  • -o, --output= β€” output file name. (default: stdout)
  • -s, --sched-stat β€” merge sched_stat and sched_switch to get events showing where and how long tasks slept. sched_switch contains a callchain where a task slept, and sched_stat contains a timeslice of how long a task slept. it's giving detective work πŸ”.
  • -k, --vmlinux=<file> β€” vmlinux pathname
  • --ignore-vmlinux β€” ignore vmlinux files.
  • --kallsyms=<file> β€” kallsyms pathname
  • --itrace β€” decode Instruction Tracing data, replacing it with synthesized events. Options are:
    • i β€” synthesize instructions events
    • y β€” synthesize cycles events
    • b β€” synthesize branches events
    • c β€” synthesize branches events (calls only)
    • r β€” synthesize branches events (returns only)
    • x β€” synthesize transactions events
    • w β€” synthesize ptwrite events
    • p β€” synthesize power events (incl. PSB events for Intel PT)
    • o β€” synthesize other events recorded due to the use of aux-output (refer to perf record)
    • I β€” synthesize interrupt or similar (asynchronous) events (e.g. Intel PT Event Trace)
    • e β€” synthesize error events
    • d β€” create a debug log
    • f β€” synthesize first level cache events
    • m β€” synthesize last level cache events
    • M β€” synthesize memory events
    • t β€” synthesize TLB events
    • a β€” synthesize remote access events
    • g β€” synthesize a call chain (use with i or x)
    • G β€” synthesize a call chain on existing event records
    • l β€” synthesize last branch entries (use with i or x)
    • L β€” synthesize last branch entries on existing event records
    • s β€” skip initial number of events
    • q β€” quicker (less detailed) decoding
    • A β€” approximate IPC
    • Z β€” prefer to ignore timestamps (so-called "timeless" decoding)
    • T β€” use the timestamp trace as kernel time

The default is all events i.e. the same as --itrace=iybxwpe, except for perf script where it is --itrace=ce.

In addition, the period (default 100000, except for perf script where it is 1) for instructions events can be specified in units of:

  • i β€” instructions
  • t β€” ticks
  • ms β€” milliseconds
  • us β€” microseconds
  • ns β€” nanoseconds (default)

Also the call chain size (default 16, max. 1024) for instructions or transactions events can be specified.

Also the number of last branch entries (default 64, max. 1024) for instructions or transactions events can be specified.

Similar to options g and l, size may also be specified for options G and L. On x86, note that G and L work poorly when data has been recorded with large PEBS. Refer linkperf:perf-intel-pt[1] man page for details.

It is also possible to skip events generated (instructions, branches, transactions, ptwrite, power) at the beginning. This is useful to ignore initialization code.

--itrace=i0nss1000000

skips the first million instructions. okay that's actually kinda cute.

The 'e' option may be followed by flags which affect what errors will or will not be reported. Each flag must be preceded by either + or -. The flags are:

  • o β€” overflow
  • l β€” trace data lost

If supported, the 'd' option may be followed by flags which affect what debug messages will or will not be logged. Each flag must be preceded by either + or -. The flags are:

  • a β€” all perf events
  • e β€” output only on errors (size configurable - see linkperf:perf-config[1])
  • o β€” output to stdout

If supported, the 'q' option may be repeated to increase the effect.

  • --strip β€” use with --itrace to strip out non-synthesized events. bye, not-synthesized besties πŸ‘‹.
  • -j, --jit β€” process jitdump files by injecting the mmap records corresponding to jitted functions. This option also generates the ELF images for each jitted function found in the jitdumps files captured in the input perf.data file. Use this option if you are monitoring an environment using JIT runtimes, such as Java, DART or V8. very demure, very JIT.
  • -f, --force β€” Don't complain, do it.
  • --vm-time-correlation[=OPTIONS] β€” some architectures may capture AUX area data which contains timestamps affected by virtualization. This option will update those timestamps in place, to correlate with host timestamps. The in-place update means that an output file is not specified, and instead the input file is modified 😳. The options are architecture specific, except that they may start with "dry-run" which will cause the file to be processed but without updating it. Currently this option is supported only by Intel PT, refer perf-intel-pt(1).
  • --guest-data=<path>,<pid>[,<time offset>[,<time scale>]] β€” insert events from a perf.data file recorded in a virtual machine at the same time as the input perf.data file was recorded on the host. The Process ID (PID) of the QEMU hypervisor process must be provided, and the time offset and time scale (multiplier) will likely be needed to convert guest time stamps into host time stamps. For example, for x86 the TSC Offset and Multiplier could be provided for a virtual machine using the Linux command line option no-kvmclock. Currently only mmap, mmap2, comm, task, context_switch, ksymbol, and text_poke events are inserted, as well as build ID information. The QEMU option -name debug-threads=on is needed so that thread names can be used to determine which thread is running which VCPU. Note libvirt seems to use this by default. When using perf record in the guest, option --sample-identifier should be used, and also --buildid-all and --switch-events may be useful. guest mode slay 🫢.
  • --convert-callchain β€” parse DWARF callchains and convert them to usual callchains. This also discards stack and register data from the samples. Heads up: this will lose inlined callchain entries. sad but true πŸ’€.
  • --guestmount=<path> β€” guest OS root file system mount directory. Users mount guest OS root directories under <path> by a specific filesystem access method, typically sshfs. For example, start 2 guest OS, one's pid is 8888 and the other's is 9999:
$ mkdir ~/guestmount
$ cd ~/guestmount
$ sshfs -o allow_other,direct_io -p 5551 localhost:/ 8888/
$ sshfs -o allow_other,direct_io -p 5552 localhost:/ 9999/
$ perf inject --guestmount=~/guestmount

🌈 SEE ALSO 🌈

perf-record(1), perf-report(1), perf-archive(1), perf-intel-pt(1)


okay that's the whole page bestie ✨ this masterpiece is from the perf manual, dated 10/31/2026, and it lives as PERF-INJECT(1) β€” periodt πŸ’…πŸŽ€

πŸ“¦ where this page comes from