Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

41.2. Configuring OProfile

Before OProfile can be run, 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.

41.2.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

NoteNote
 

The debuginfo package must be installed (which contains the uncompressed kernel) in order to monitor the kernel.

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. Refer to Section 41.6 Understanding /dev/oprofile/ for details about this directory.

NoteNote
 

Even if OProfile is configured not to profile the kernel, the SMP kernel still must be running so that the oprofile module can be loaded from it.

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, refer to Section 41.2.3 Separating Kernel and User-space Profiles.

41.2.2. Setting Events to Monitor

Most processors contain counters, which are used by OProfile to monitor specific events. As shown in Table 41-2, the number of counters available depends on the processor.

Processorcpu_typeNumber of Counters
Pentium Proi386/ppro2
Pentium IIi386/pii2
Pentium IIIi386/piii2
Pentium 4 (non-hyper-threaded)i386/p48
Pentium 4 (hyper-threaded)i386/p4-ht4
Athloni386/athlon4
AMD64x86-64/hammer4
Itaniumia64/itanium4
Itanium 2ia64/itanium24
TIMER_INTtimer1
IBM eServer iSeries and pSeriestimer1
 ppc64/power48
 ppc64/power56
 ppc64/9708
IBM eServer S/390 and S/390xtimer1
IBM eServer zSeriestimer1

Table 41-2. OProfile Processors and Counters

Use Table 41-2 to verify that the correct processor type was detected and to determine the number of events that can be monitored simultaneously. timer is used as the processor type if the processor does not have supported performance monitoring hardware.

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 counter 0 are not set to an event by default. The default events monitored are shown in Table 41-3.

ProcessorDefault Event for CounterDescription
Pentium Pro, Pentium II, Pentium III, Athlon, AMD64CPU_CLK_UNHALTEDThe processor's clock is not halted
Pentium 4 (HT and non-HT)GLOBAL_POWER_EVENTSThe time during which the processor is not stopped
Itanium 2CPU_CYCLESCPU Cycles
TIMER_INT(none)Sample for each timer interrupt
ppc64/power4CYCLESProcessor Cycles
ppc64/power5CYCLESProcessor Cycles
ppc64/970CYCLESProcessor Cycles

Table 41-3. Default Events

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:

cat /dev/oprofile/cpu_type

The events available vary depending on the processor type. To determine the events available for profiling, execute the following command as root (the list is specific to the system's processor type):

op_help

The events for each counter can be configured via the command line or with a graphical interface. For more information on the graphical interface, refer to Section 41.8 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 op_help, and replace <sample-rate> with the number of events between samples.

41.2.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 whatever the jiffy rate is 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.

CautionCaution
 

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

41.2.2.2. Unit Masks

If the cpu_type is not timer, unit masks may also be required to further define the event.

Unit masks for each event are listed with the op_help 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>

41.2.3. Separating Kernel and User-space Profiles

By default, kernel mode and user mode information is gathered for each event. To configure OProfile not to count 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 not to count events in user mode for a specific counter, execute the following command:

opcontrol --event=<event-name>:<sample-rate>:<unit-mask>:<kernel>:0

Execute the following command to start profiling user mode for the counter again:

opcontrol --event=<event-name>:<sample-rate>:<unit-mask>:<kernel>: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>

<choice> 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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire