Chapter 1. Introduction

Table of Contents

1. OProfile legacy mode
2. OProfile perf_events mode
3. Applications of OProfile
3.1. Support for dynamically compiled (JIT) code
3.2. No support for virtual machine guests
4. System requirements
5. Internet resources
6. Installation
7. Uninstalling OProfile

This manual applies to OProfile version 0.9.8. OProfile is a profiling system for Linux 2.6 and higher systems on a number of architectures. It is capable of profiling all parts of a running system, from the kernel (including modules and interrupt handlers) to shared libraries to binaries. OProfile can profile the whole system in the background, collecting information at a low overhead. These features make it ideal for profiling entire systems to determine bottle necks in real-world systems.

Many CPUs provide "performance counters", hardware registers that can count "events"; for example, cache misses, or CPU cycles. OProfile provides profiles of code based on the number of these occurring events: repeatedly, every time a certain (configurable) number of events has occurred, the PC value is recorded. This information is aggregated into profiles for each binary image.

Some hardware setups do not allow OProfile to use performance counters: in these cases, no events are available so OProfile operates in timer mode, as described in later chapters. Timer mode is only available in "legacy mode" (see Section 1, “OProfile legacy mode”).

1. OProfile legacy mode

"Legacy" OProfile consists of the opcontrol shell script, the oprofiled daemon, and several post-processing tools (e.g., opreport). The opcontrol script 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. Using OProfile in "legacy mode" requires root user authority since the profiling is done on a system-wide basis, which may (if misused) cause adverse effects to the system.

Note

Profiling setup parameters that you specify using opcontrol are cached in /root/.oprofile/daemonrc. Subsequent runs of opcontrol --start will continue to use these cached values until you override them with new values.