Product SiteDocumentation Site

Chapter 20. OProfile

20.1. Overview of Tools
20.1.1. operf vs. opcontrol
20.2. Using operf
20.2.1. Specifying the Kernel
20.2.2. Setting Events to Monitor
20.2.3. Categorization of Samples
20.3. Configuring OProfile Using Legacy Mode
20.3.1. Specifying the Kernel
20.3.2. Setting Events to Monitor
20.3.3. Separating Kernel and User-space Profiles
20.4. Starting and Stopping OProfile Using Legacy Mode
20.5. Saving Data in Legacy Mode
20.6. Analyzing the Data
20.6.1. Using opreport
20.6.2. Using opreport on a Single Executable
20.6.3. Getting More Detailed Output on the Modules
20.6.4. Using opannotate
20.7. Understanding the /dev/oprofile/ directory
20.8. Example Usage
20.9. OProfile Support for Java
20.9.1. Profiling Java Code
20.10. Graphical Interface
20.11. OProfile and SystemTap
20.12. Additional Resources
OProfile is a low overhead, system-wide performance monitoring tool. It uses the performance monitoring hardware on the processor to retrieve information about the kernel and executables on the system, such as when memory is referenced, the number of L2 cache requests, and the number of hardware interrupts received. On a Fedora system, the oprofile package must be installed to use this tool.
Many processors include dedicated performance monitoring hardware. This hardware makes it possible to detect when certain events happen (such as the requested data not being in cache). The hardware normally takes the form of one or more counters that are incremented each time an event takes place. When the counter value increments, an interrupt is generated, making it possible to control the amount of detail (and therefore, overhead) produced by performance monitoring.
OProfile uses this hardware (or a timer-based substitute in cases where performance monitoring hardware is not present) to collect samples of performance-related data each time a counter generates an interrupt. These samples are periodically written out to disk; later, the data contained in these samples can then be used to generate reports on system-level and application-level performance.
Be aware of the following limitations when using OProfile:

20.1. Overview of Tools

Table 20.1, “OProfile Commands” provides a brief overview of the most commonly used tools provided with the oprofile package.
Table 20.1. OProfile Commands
Command Description
Displays available events for the system's processor along with a brief description of each.
Converts sample database files from a foreign binary format to the native format for the system. Only use this option when analyzing a sample database from a different architecture.
opannotate Creates annotated source for an executable if the application was compiled with debugging symbols. See Section 20.6.4, “Using opannotate for details.
Configures what data is collected. See Section 20.3, “Configuring OProfile Using Legacy Mode” for details.
Recommended tool to be used in place of opcontrol for profiling. See Section 20.2, “Using operf” for details.
For differences between operf and opcontrol see Section 20.1.1, “operf vs. opcontrol”.
Retrieves profile data. See Section 20.6.1, “Using opreport for details.
Runs as a daemon to periodically write sample data to disk.

20.1.1. operf vs. opcontrol

There are two mutually exclusive methods for collecting profiling data with OProfile. You can either use the newer and preferred operf or the opcontrol tool.


This is the recommended mode for profiling. The operf tool uses the Linux Performance Events Subsystem, and therefore does not require the oprofile kernel driver. The operf tool allows you to target your profiling more precisely, as a single process or system-wide, and also allows OProfile to co-exist better with other tools using the performance monitoring hardware on your system. Unlike opcontrol, it can be used without the root privileges. However, operf is also capable of system-wide operations with use of the --system-wide option, where root authority is required.
With operf, there is no initial setup needed. You can invoke operf with command-line options to specify your profiling settings. After that, you can run the OProfile post-processing tools described in Section 20.6, “Analyzing the Data”. See Section 20.2, “Using operf” for further information.


This mode consists of the opcontrol shell script, the oprofiled daemon, and several post-processing tools. The opcontrol command is used for configuring, starting, and stopping a profiling session. An OProfile kernel driver, usually built as a kernel module, is used for collecting samples, which are then recorded into sample files by oprofiled. You can use legacy mode only if you have root privileges. In certain cases, such as when you need to sample areas with disabled interrupt request (IRQ), this is a better alternative.
Before OProfile can be run in legacy mode, it must be configured as shown in Section 20.3, “Configuring OProfile Using Legacy Mode”. These settings are then applied when starting OProfile (Section 20.4, “Starting and Stopping OProfile Using Legacy Mode”).