24.3. Configuring OProfile Using Legacy Mode

Before OProfile can be run in legacy mode, it must be configured. At a minimum, selecting to monitor the kernel (or selecting not to monitor the kernel) is required. The following sections describe how to use the opcontrol utility to configure OProfile. As the opcontrol commands are executed, the setup options are saved to the /root/.oprofile/daemonrc file.

24.3.1. Specifying the Kernel

First, configure whether OProfile should monitor the kernel. This is the only configuration option that is required before starting OProfile. All others are optional.
To monitor the kernel, execute the following command as root:
opcontrol --setup --vmlinux=/usr/lib/debug/lib/modules/`uname -r`/vmlinux

Important

In order to monitor the kernel, the kernel-debuginfo package which contains the uncompressed kernel must be installed. For more information on how to install this package, see the How to download debuginfo packages like kernel-debuginfo? article on the Red Hat Customer Portal.
To configure OProfile not to monitor the kernel, execute the following command as root:
opcontrol --setup --no-vmlinux
This command also loads the oprofile kernel module, if it is not already loaded, and creates the /dev/oprofile/ directory, if it does not already exist. See Section 24.7, “Understanding the /dev/oprofile/ directory” for details about this directory.
Setting whether samples should be collected within the kernel only changes what data is collected, not how or where the collected data is stored. To generate different sample files for the kernel and application libraries, see Section 24.3.3, “Separating Kernel and User-space Profiles”.

24.3.2. Setting Events to Monitor

Most processors contain counters, which are used by OProfile to monitor specific events. As shown in Table 24.3, “OProfile Processors and Counters”, the number of counters available depends on the processor.

Table 24.3. OProfile Processors and Counters

Processor cpu_type Number of Counters
AMD64 x86-64/hammer 4
AMD Family 10h x86-64/family10 4
AMD Family 11h x86-64/family11 4
AMD Family 12h x86-64/family12 4
AMD Family 14h x86-64/family14 4
AMD Family 15h x86-64/family15 6
Applied Micro X-Gene arm/armv8-xgene 4
ARM Cortex A53 arm/armv8-ca53 6
ARM Cortex A57 arm/armv8-ca57 6
IBM eServer System i and IBM eServer System p timer 1
IBM POWER4 ppc64/power4 8
IBM POWER5 ppc64/power5 6
IBM PowerPC 970 ppc64/970 8
IBM PowerPC 970MP ppc64/970MP8
IBM POWER5+ppc64/power5+6
IBM POWER5++ppc64/power5++6
IBM POWER56ppc64/power66
IBM POWER7ppc64/power76
IBM POWER8ppc64/power78
IBM S/390 and IBM System z timer 1
Intel Core i7 i386/core_i7 4
Intel Nehalem microarchitecture i386/nehalem 4
Intel Westmere microarchitecture i386/westmere 4
Intel Haswell microarchitecture (non-hyper-threaded)i386/haswell8
Intel Haswell microarchitecture (hyper-threaded)i386/haswell-ht4
Intel Ivy Bridge microarchitecture (non-hyper-threaded)i386/ivybridge8
Intel Ivy Bridge microarchitecture (hyper-threaded)i386/ivybridge-ht4
Intel Sandy Bridge microarchitecture (non-hyper-threaded)i386/sandybridge8
Intel Sandy Bridge microarchitecturei386/sandybridge-ht4
Intel Broadwell microarchitecture (non-hyper-threaded)i386/broadwell8
Intel Broadwell microarchitecture (hyper-threaded)i386/broadwell-ht4
Intel Silvermont microarchitecturei386/silvermont2
TIMER_INT timer 1
Use Table 24.3, “OProfile Processors and Counters” to determine the number of events that can be monitored simultaneously for your CPU type. If the processor does not have supported performance monitoring hardware, the timer is used as the processor type.
If timer is used, events cannot be set for any processor because the hardware does not have support for hardware performance counters. Instead, the timer interrupt is used for profiling.
If timer is not used as the processor type, the events monitored can be changed, and counter 0 for the processor is set to a time-based event by default. If more than one counter exists on the processor, the counters other than 0 are not set to an event by default. The default events monitored are shown in Table 24.4, “Default Events”.

Table 24.4. Default Events

Processor Default Event for Counter Description
AMD Athlon and AMD64 CPU_CLK_UNHALTED The processor's clock is not halted
AMD Family 10h, AMD Family 11h, AMD Family 12h CPU_CLK_UNHALTED The processor's clock is not halted
AMD Family 14h, AMD Family 15h CPU_CLK_UNHALTED The processor's clock is not halted
Applied Micro X-Gene CPU_CYCLES Processor Cycles
ARM Cortex A53 CPU_CYCLES Processor Cycles
ARM Cortex A57 CPU_CYCLES Processor Cycles
IBM POWER4 CYCLES Processor Cycles
IBM POWER5 CYCLES Processor Cycles
IBM POWER8 CYCLES Processor Cycles
IBM PowerPC 970 CYCLES Processor Cycles
Intel Core i7 CPU_CLK_UNHALTED The processor's clock is not halted
Intel Nehalem microarchitecture CPU_CLK_UNHALTED The processor's clock is not halted
Intel Pentium 4 (hyper-threaded and non-hyper-threaded) GLOBAL_POWER_EVENTS The time during which the processor is not stopped
Intel Westmere microarchitecture CPU_CLK_UNHALTED The processor's clock is not halted
Intel Broadwell microarchitecture CPU_CLK_UNHALTED The processor's clock is not halted
Intel Silvermont microarchitecture CPU_CLK_UNHALTED The processor's clock is not halted
TIMER_INT (none) Sample for each timer interrupt
The number of events that can be monitored at one time is determined by the number of counters for the processor. However, it is not a one-to-one correlation; on some processors, certain events must be mapped to specific counters. To determine the number of counters available, execute the following command:
ls -d /dev/oprofile/[0-9]*
The events available vary depending on the processor type. Use the ophelp command to determine the events available for profiling. The list is specific to the system's processor type.
ophelp

Note

Unless OProfile is properly configured, ophelp fails with the following error message:
Unable to open cpu_type file for reading
Make sure you have done opcontrol --init
cpu_type 'unset' is not valid
you should upgrade oprofile or force the use of timer mode
To configure OProfile, follow the instructions in Section 24.3, “Configuring OProfile Using Legacy Mode”.
The events for each counter can be configured via the command line or with a graphical interface. For more information on the graphical interface, see Section 24.10, “Graphical Interface”. If the counter cannot be set to a specific event, an error message is displayed.
To set the event for each configurable counter via the command line, use opcontrol:
opcontrol --event=event-name:sample-rate
Replace event-name with the exact name of the event from ophelp, and replace sample-rate with the number of events between samples.

24.3.2.1. Sampling Rate

By default, a time-based event set is selected. It creates a sample every 100,000 clock cycles per processor. If the timer interrupt is used, the timer is set to the respective rate and is not user-settable. If the cpu_type is not timer, each event can have a sampling rate set for it. The sampling rate is the number of events between each sample snapshot.
When setting the event for the counter, a sample rate can also be specified:
opcontrol --event=event-name:sample-rate
Replace sample-rate with the number of events to wait before sampling again. The smaller the count, the more frequent the samples. For events that do not happen frequently, a lower count may be needed to capture the event instances.

Warning

Be extremely careful when setting sampling rates. Sampling too frequently can overload the system, causing the system to appear frozen or causing the system to actually freeze.

24.3.2.2. Unit Masks

Some user performance monitoring events may also require unit masks to further define the event.
Unit masks for each event are listed with the ophelp command. The values for each unit mask are listed in hexadecimal format. To specify more than one unit mask, the hexadecimal values must be combined using a bitwise or operation.
opcontrol --event=event-name:sample-rate:unit-mask
Note that on certain architectures, there can be multiple unit masks with the same hexadecimal value. In that case they have to be specified by their names only.

24.3.3. Separating Kernel and User-space Profiles

By default, kernel mode and user mode information is gathered for each event. To configure OProfile to ignore events in kernel mode for a specific counter, execute the following command:
opcontrol --event=event-name:sample-rate:unit-mask:0
Execute the following command to start profiling kernel mode for the counter again:
opcontrol --event=event-name:sample-rate:unit-mask:1
To configure OProfile to ignore events in user mode for a specific counter, execute the following command:
opcontrol --event=event-name:sample-rate:unit-mask:1:0
Execute the following command to start profiling user mode for the counter again:
opcontrol --event=event-name:sample-rate:unit-mask:1:1
When the OProfile daemon writes the profile data to sample files, it can separate the kernel and library profile data into separate sample files. To configure how the daemon writes to sample files, execute the following command as root:
opcontrol --separate=choice
The choice argument can be one of the following:
  • none — Do not separate the profiles (default).
  • library — Generate per-application profiles for libraries.
  • kernel — Generate per-application profiles for the kernel and kernel modules.
  • all — Generate per-application profiles for libraries and per-application profiles for the kernel and kernel modules.
If --separate=library is used, the sample file name includes the name of the executable as well as the name of the library.

Note

These configuration changes will take effect when the OProfile profiler is restarted.