Linux Code Performance Detection Tool (iii)-Control Analyzer Opcontrol use instructions __linux

The following chapters are a detailed introduction to Oprofile, interested in children's shoes can continue to read, these chapters are selected from the oprofile of the use of the guide, to understand the Oprofile analysis principles and scope of application is very helpful, is a bit boring: (

In this section, we discuss the core-opcontrol configuration of Oprofile analysis system in depth. Opcontrol script (Note that it is not an executable program OH) There is a default configuration, use this default configuration can do some simple analysis, if you want to in-depth analysis, you need to change the Opcontrol script settings options, Especially when using hardware support performance counters (performance counter).

Oprofile supports many counters, each of which can be counted by an event, such as cache misses or MMX operations. The count of these events is used by oprofile to react to the results of the analysis: the functions or binaries that are listed in the previous analysis can reflect that most of the selected events occurred in the code.

In addition, each counter has a "count value" (count), which determines the degree of detail of the analysis, the smaller the value, the more frequent the sampling, and currently consumes a lot of system resources. Each counter can choose to sample only kernel code, sample user state code, or all samples. Finally, some events contain a "unit mask", which is used to further limit the types of events to be counted. 1.1 Opcontrol main parameter Description

--init

Load the Oprofile module when needed and start the Oprofile driver interface.

--setup

Used when setting up the analyzer, followed by the parameter list, which is saved in the/ROOT/.OPROFILE/DAEMONRC file. This setting is not necessary, the simplest case you can set this way: Opcontrol--no-vmlinux.

--status

Displays configuration information.

--start-daemon

Open the profiling background service, but do not parse the sample. Analysis samples can be performed using--start. This startup is useful when you need to eliminate the impact of Oprofile background service startup on sampling, because--start simply writes a file in Oprofilefs. Note: Not available on the 2.2 and 2.4 cores.

--start

Use the parameters set by--setup or start data collection using parameters saved in the/ROOG/.OPROFILE/DAEMONRC file (profiling sampling). If you perform the--verbose option, the background service generates a lot of debugging information.

--dump

Forces the collected sampled data to be written to the background service.

--stop

Stop data collection (This step does not apply in the 2.2, 2.4 kernel).

--shutdown

Stop data acquisition and turn off background services.

--reset

Data is purged from the current session, and the saved session is not purged.

--save=session_name

Saves data from the current drawing to the Session_name session.

--list-events

Lists the time type and unitmasks.

--help

Print use Help information.

--EVENT=[EVENTSPEC]

Performs a sampling analysis using the specified performance counters.

--session-dir=dir_path

Create/Use the Dir_path database, or use the default directory database (/var/lib/oprofile) if unspecified.

--separate=[none,lib,kernel,thread,cpu,all]

By default, each collection analysis is saved in a separate file, such as C library sampling is/LIB/LIBC.O sampling data, but you can use the following parameters to create a separate sample file:

Table 2‑1 Analysis Parameters table

None	No separate sample data (default configuration)
Lib	For libraries, each application creates a separate set of profiling data
Kernel	For kernel modules, each application creates a separate profiling data
Thread	Create separate profiling data for each thread and task
Cpu	Create separate profiling data for each CPU
All	Contains all of the above parameters

Note:--separate=kernel will open--separate=lib.

Using--separate=kernel creates a large number of sample files in a short period of time and is often useful for short sessions or for image filtering (image filtering).

--callgraph= #depth

Sets the maximum value of the call depth when sampling, and 0 disables call graph profiling. Note: This feature is available on only a limited number of platforms, such as:

A x86 platform for installing the 2.6 kernel

B Install the 2.6-core ARM platform

(c) Installation of 2.6.17 PowerPC platform

--image=image,[images]| " All

Image filtering. If you specify an absolute path for one or more binary images, oprofile only produces the parsing resolution of those images. This is useful when the analysis results are many, such as when using--separate=thread. The default value is all.

--vmlinux=file

Vmlinux kernel image.

--no-vmlinux when there is no kernel vmlinux file to use this parameter, use this parameter will not analyze the kernel again, want to analyze the kernel performance of child shoes with caution. However, after using it, Oprofile can still calculate the total number of kernel samples, but not the symbolic results of the kernel.

1.1 using the example Intel Performance Counter Setup steps:

The above (step 1--step 7) is the setup steps for analyzing a.out using the Intel performance counter, which implements the start Opcontrol-> setting opcontrol-> starting sampling-> running the test program-> sampling data Collection-        > Stop profiling sampling-> close Opcontrol. However, the operation in the diagram does not view the sample results, and to see the results of the analysis, the Opreport and opannotate tools are used, and the use of the two tools is described in detail in chapter Iii.

RTC Mode Settings

Because this mode only applies 2.2, 2.4 cores, realizes the wood to have the environment, therefore can only paste a mannual on the picture, really has the demand the child shoes to see Oprofile original E mannual.

Timer Interrupt mode (timerinterrupt mode)

Note: This mode only supports 2.6 kernel, the old version of the core children's shoes do not look wrong slightly.