The perf tool provides statistics for both user and kernel events occurring in the system. It can function in two modes:

• Event counting (perf stat): This counts events in kernel context and prints statistics at the end. It has the least overhead.
• Event sampling (perf record): This writes the gathered data to a file at a given sampling period. The data can then be read as profiling (perf report) or trace data (perf script). Gathering data to a file can be resource intensive and the file can quickly grow in size.

By default, perf counts events for all the threads in the given command, including child processes, until the command finishes or is interrupted.

A generic way to run perf is as follows:

perf stat|record [-e <comma separated event list> --filter '<expr>'] 
   [-o <filename>] [--] <command> [<arguments>] 

Let's explain the preceding arguments in more detail:

• e: This specifies an event list to use instead of the default set of events. An event filter can also be specified, with its syntax explained in the Linux kernel source documentation at: Documentation/trace/events.txt.
• o: This specifies the output file name, by default perf.data.
• --: This is used as a separator when the command needs arguments.

It can also start sampling a running process by passing the -p <pid> option.

We can obtain a list of all available events by executing the following command:

# perf list  

Or on a specific subsystem with the following command:

# perf list '<subsystem>:*'  

You can also access raw PMU events directly by using the r<event> event, for example, to read the data cache misses on an ARM core:

# perf stat -e r3 sleep 5
Performance counter stats for 'sleep 5':
            12791      r3                                                          
    5.006582001 seconds time elapsed
  

Unless specified, perf record will sample hardware events at an average rate of 1000 Hz, but the rate can be modified with the -F <freq> argument. Tracepoints will be counted on each occurrence.