Table of Contents
After collecting profile data, the raw data must undergo special processing in order for you to perform your analysis. The analysis tools that perform this special processing are opreport, opannotate, and opgprof. Additionally, the oparchive is used to gather together profile data, sampled binary files, etc. for the purpose of off-line analysis. While not really an analysis tool, oparchive is put in that category for convenience since it takes many of the same options as the other analysis tools.
All of the analysis tools take a profile specification as an input argument. This is a set of definitions that describes the specific profile data that should be examined. The simplest profile specification is empty: this will match all the available profile files for the current session.
Specification parameters are of the form name:value[,value].
For example, if I wanted to get a combined symbol summary for
/bin/myprog and /bin/myprog2,
I could do opreport -l image:/bin/myprog,/bin/myprog2.
As a special case, you don't actually need to specify the image:
part of the specification. Anything left on the command line after all other
opreport options have been processed is assumed to be an
image: name. Similarly, if no session:
is specified, then session:current is assumed ("current"
is a special name of the current (i.e., most recent) profiling session).
In addition to the comma-separated list shown above, some of the
specification parameters can take glob-style
values. For example, if I want to see image summaries for all
binaries profiled in /usr/bin/, I could do
opreport image:/usr/bin/\*. Note the necessity
to escape the special character from the shell.
For opreport, profile specifications can be used to define two profiles, giving differential output. This is done by enclosing each of the two specifications within curly braces, as shown in the examples below. Any specifications outside of curly braces are shared across both.
Image summaries for all profiles with DATA_MEM_REFS
samples in the saved session called "stresstest" :
# opreport session:stresstest event:DATA_MEM_REFS |
Symbol summary for the application called "test_sym53c8xx,9xx". Note the
escaping is necessary as image: takes a comma-separated list.
# opreport -l ./test/test_sym53c8xx\,9xx |
Image summaries for all binaries in the test directory,
excepting boring-test :
# opreport image:./test/\* image-exclude:./test/boring-test |
Differential profile of a binary stored in two archives :
# opreport -l /bin/bash { archive:./orig } { archive:./new }
|
Differential profile of an archived binary with the current session :
# opreport -l /bin/bash { archive:./orig } { }
|
archive:
archivepath
A path to an archive made with oparchive. Absence of this tag, unlike others, means "the current system", equivalent to specifying "archive:".
session:
sessionlist
A comma-separated list of session names to resolve in. Absence of this tag, unlike others, means "the current session", equivalent to specifying "session:current".
session-exclude:
sessionlist
A comma-separated list of sessions to exclude.
image:
imagelist
A comma-separated list of image names to resolve. Each entry may be relative path, glob-style name, or full path, e.g.
opreport 'image:/usr/bin/oprofiled,*op*,./opreport' |
image-exclude:
imagelist
Same as image:, but the matching images are excluded.
lib-image:
imagelist
Same as image:, but only for images that are for
a particular primary binary image (namely, an application).
lib-image-exclude:
imagelist
Same as lib-image:, but the matching images
are excluded.
event:
eventlist
The symbolic event name to match on, e.g. event:DATA_MEM_REFS.
You can pass a list of events for side-by-side comparison with opreport.
count:
eventcountlist
The event count to match on, e.g. event:DATA_MEM_REFS count:30000.
Note that this value refers to the count value in the event spec you passed
to operf when setting up to do a
profile run. It has nothing to do with the sample counts in the profile data
itself.
You can pass a list of events for side-by-side comparison with opreport.
unit-mask:
masklist
The unit mask value of the event to match on, e.g. unit-mask:1.
You can pass a list of events for side-by-side comparison with opreport.
cpu:
cpulist
Only consider profiles for the given numbered CPU (starting from zero). This is only useful when using CPU profile separation.
tgid:
pidlist
Only consider profiles for the given task groups. Unless some program is using threads, the task group ID of a process is the same as its process ID. This option corresponds to the POSIX notion of a thread group. This is only useful when using per-process profile separation.
tid:
tidlist
Only consider profiles for the given threads. When using
recent thread libraries, all threads in a process share the
same task group ID, but have different thread IDs. You can
use this option in combination with tgid: to
restrict the results to particular threads within a process.
This is only useful when using per-process profile separation.
Each session's sample files can be found in the $SESSION_DIR/samples/ directory (default
for operf is <cur_dir>/oprofile_data/samples/).
These are used, along with the binary image files, to produce human-readable data.
In some circumstances (e.g., kernel modules), OProfile
will not be able to find the binary images. All the tools have an --image-path
option to which you can pass a comma-separated list of alternate paths to search. For example,
I can let OProfile find my 2.6 modules by using --image-path /lib/modules/2.6.0/kernel/.
It is your responsibility to ensure that the correct images are found when using this
option.
Note that if a binary image changes after the sample file was created, you won't be able to get useful symbol-based data out. This situation is detected for you. If you replace a binary, you should make sure to save the old binary if you need to do comparative profiles.
When attempting to get output, you may see the error :
error: no sample files found: profile specification too strict ? |
What this is saying is that the profile specification you passed in, when matched against the available sample files, resulted in no matches. There are a number of reasons this might happen:
You specified a binary name, but spelt it wrongly. Check your spelling !
Make very sure that OProfile was actually up and running when you ran the application you wish to profile.
Remember OProfile is a statistical profiler - you're not guaranteed to get samples for short-running programs. You can help this by using a lower count for the performance counter, so there are a lot more samples taken per second.
Similarly, if the application spends little time in the main binary image itself, with most of it spent in shared libraries it uses, you might not see any samples for the binary image (i.e., executable) itself.
For example, you specified something like tgid:3433,
but no task with that group ID ever ran the code.
If you're profiling a particular event, for example counting MMX operations, the code might simply have not generated any events in the first place. Verify the code you're profiling does what you expect it to.
If you're trying to get reports for a kernel
module, make sure to use the -p option, and specify the
module name with the .ko
extension. Check if the module is one loaded from initrd.