Table of Contents
OK, so the profiler has been running, but it's not much use unless we can get some data out. Fairly often, OProfile does a little too good a job of keeping overhead low, and no data reaches the profiler. This can happen on lightly-loaded machines. Remember you can force a dump at any time with :
opcontrol --dump
Remember to do this before complaining there is no profiling data ! Now that we've got some data, it has to be processed. That's the job of opreport, opannotate, or opgprof.
All of the analysis tools take a profile specification. This is a set of definitions that describe which actual profiles should be examined. The simplest profile specification is empty: this will match all the available profile files for the current session (this is what happens when you do opreport).
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 here: anything left on the command line 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 / last 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). This only
makes sense to use if you're using --separate.
This includes kernel modules and the kernel when using
--separate=kernel.
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.
When using the timer interrupt, the event is always "TIMER".
count:
eventcountlist
The event count to match on, e.g. event:DATA_MEM_REFS count:30000.
Note that this value refers to the setting used for opcontrol
only, and 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.
When using the timer interrupt, the count is always 0 (indicating it cannot be set).
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: /var/lib/oprofile/samples/).
These are used, along with the binary image files, to produce human-readable data.
In some circumstances (kernel modules in an initrd, or modules on 2.6 kernels), 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 binary.
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 binary 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 itself. You can check this by using opcontrol --separate=lib before the profiling session, so opreport and friends show the library profiles on a per-application basis.
For example, you specified something like tgid:3433,
but no task with that group ID ever ran the code.
If you're using a particular event counter, 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 using 2.6 kernels, and 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.