oprofile Log


Commit Date  
[771596] by Maynard Johnson Maynard Johnson

Various documentation cleanups

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-08-08 18:08:11 Tree
[bd140d] by Carl Love Carl Love , pushed by Maynard Johnson Maynard Johnson

Oprofile, opreport: fix to pass string of options from opannotate to objdump

Currently when passing a quoted string of two or more options from
opannotate to objdump, the objdump command fails. The issue is when
an argument string passed to exec_command contains spaces.
This patch takes the quoted string of options to pass to objdump and
breaks the list of options up into individual arguments. The objdump_params
is then updated so that there is one argument in each element of the vector
rather than string elements that may contain spaces.

This patch also updates the man page with examples of how to pass options
to the objdump from the opreport command.

Signed-off-by: Carl Love <cel@us.ibm.com>

2012-08-06 19:26:38 Tree
[44b633] by Maynard Johnson Maynard Johnson

Cleanup verbose variable usage in operf for easier debugging

This patch removes the "perf_events" verbose option which had
been used to enable debugging for both the recording phase of
profiling (where profile data from the kernel is being read by
the operf-record process) and the conversion phase. Instead,
two new distinct verbose options are introduced: "record" and
"convert".

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-08-06 00:45:54 Tree
[021390] by Maynard Johnson Maynard Johnson

Add a new option to operf to do conversion to oprofile format after profiling is done

The profile data read from the perf_events kernel has to be converted to OProfile
format for the post-processing tools (e.g., opreport). By default, this conversion
is done on-the-fly during profling using a pipe. This method involves starting an
additional operf process that reads the data fed into the pipe by the operf-record
process. This additional process interprets the perf_events data and does the
conversion to OProfile format, persisting the ususal oprofile sample data files in
<session-dir>/samples/current. When operf is run in single application mode, the
extra overhead of the conversion process running during profiling time is not even
recorded, and thus is not easily noticeable. However, when doing a system-wide
profile, operf overhead can be substantial (easily over 6% on a busy system), and
the samples for operf *are* noticeable in the system-wide report.

This patch introduces the "--lazy-conversion" option which directs operf to write
the perf_events profile data to a temporary file during profiling. Then, after
profiling is done, the data in the temporary file is converted to OProfile format.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-08-06 00:44:22 Tree
[2af280] by Maynard Johnson Maynard Johnson

Fix operf profiling of forked processes

When an application being profiled by operf does a fork, and where
that forked process does *not* do an exec after the fork, any work
performed by the forked process was not being profied. This patch
addresses that problem.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-08-06 00:42:50 Tree
[b12f64] by Maynard Johnson Maynard Johnson

Change pp tools to abort if <cur_dir>/oprofile_data exists, but no samples found

In commit 01c7ce945cfe835b908c5f4f8c1125e65302b000 on July 3, 2012,
a change was made to the post-processing tools to look first in
<cur_dir>/oprofile_data; then, if no samples are found there,
the tool should fall back to the "standard" /var/lib/oprofile
session-dir. I've come the conclusion that this is not proper
behavior. For example, a user may run operf using some event that
never occurs during the profiling run, and, thus, no samples would
be stored in <cur_dir>/oprofile_data. But if that user then ran
opreport and there happened to be some old profile data in
/var/lib/oprofile, that old profile data would be displayed in
the report.

This new patch changes the behavior as follows:
The post-processing analysis tools will search for samples in
<current_dir>/oprofile_data first. If that directory exists
but has no samples, then the usual "No sample file found"
message is displayed. On the other hand, if that directory
does not exist, the post-processing tools use the standard
session-dir of /var/lib/oprofile. Also, the message that
indicates the session-dir being used will be displayed
whether or not samples are found so that users can see
clearly where the pp tool was looking for samples.

This patch also makes a small change in the "No sample file found"
message relating to the use of 'opcontrol --dump', which is only
appropriate when using legacy profiling versus operf profiling.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-07-31 17:05:56 Tree
[d3c656] by Maynard Johnson Maynard Johnson

Fix operf to read unit mask in hex and document unit mask spec requirementes

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-07-26 16:02:39 Tree
[f63504] by Maynard Johnson Maynard Johnson

Bug #3386923: Document that 'opannoate -a' needs symbol info

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-07-23 21:13:06 Tree
[a30a67] by Maynard Johnson Maynard Johnson

[PATCH] Add some helpful messages for various operf usage scenarios

Added the folowing helpful messages:
- Display message in opreport (and other pp tools) to show session dir used.
- When using operf with "-p" or "-s", print message that user can do "ctrl-C"
or "kill SIGINT <operf_PID> " to stop profiling. The "kill" command is mainly
needed in the case where operf is made a background job via the '&'.
- Display a message when a permissions error is encountered when trying to mmap
the kernel profile data. This can happen when a given user tries to run multiple
instances of operf simultaneously. This problem is fixed on newer kernels (e.g., 3.0).
- For 'operf --system-wide', print a message that either the user needs to be root or
the perf_event_paranoid system value must be 0 or -1. Of course, the message is
printed only if neither of these are true.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-07-19 12:23:03 Tree
[b862e4] by Maynard Johnson Maynard Johnson

Fix up oprofile user manual to add info about new operf program

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-07-18 15:07:04 Tree
[6bc578] by Maynard Johnson Maynard Johnson

Document non-support for event-based profiling in guest environments

Doc fix for bug #3393079.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-07-06 15:12:22 Tree
[01c7ce] by Maynard Johnson Maynard Johnson

Make opreport use <cur_dir>/oprofile data for default session-dir

Since operf will be the recommended profiling tool in the future
(instead of opcontrol) and since operf stores the sample data by
default in <cur_dir>/oprofile_data, it makes sense for opreport
and other oprofile post-processing tools to look first in
<cur_dir/oprofile_data; then, if no samples are found there, the
tool should fall back to the "standard" /var/lib/oprofile session-dir.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-07-03 19:15:19 Tree
[589207] by Maynard Johnson Maynard Johnson

Remove unused "--kernel-buffersize-multiplier" option from operf

The "--kernel-buffersize-multiplier" option was not wired in to
perform any actions. In the course of wiring it in to the mmap
call (where the operf record process mmap's the perf_events kernel
data) and performing functional tests, I found that bumping up
the mmap size had little noticeable beneficial effect -- perhaps
even *no* effect at all. I expected that the perf_event_header type
of PERF_RECORD_LOST would be an indication that a larger kernel
buffer (i.e., mmap'ed area) was needed. I was able to force such
"LOST" samples by using a very high sampling rate, yet increasing
the number mmap pages did not eliminate the LOST samples. So I
removed this option from the code and the man page.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-06-25 20:54:33 Tree
[3d9018] by Maynard Johnson Maynard Johnson

Add comment in operf man page about using ophelp to list available events

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-06-12 18:56:02 Tree
[d17626] by Maynard Johnson Maynard Johnson

Add reporting of profiling statistics to operf.

This patch adds the recording of the following stats:

OPERF_SAMPLES, /**< nr. samples */
OPERF_KERNEL, /**< nr. kernel samples */
OPERF_PROCESS, /**< nr. userspace samples */
OPERF_INVALID_CTX, /**< nr. samples lost due to sample address not in expected range for domain */
OPERF_LOST_KERNEL, /**< nr. kernel samples lost */
OPERF_LOST_SAMPLEFILE, /**< nr samples for which sample file can't be opened */
OPERF_LOST_NO_MAPPING, /**< nr samples lost due to no mapping */
OPERF_NO_APP_KERNEL_SAMPLE, /**<nr. user ctx kernel samples dropped due to no app context available */
OPERF_NO_APP_USER_SAMPLE, /**<nr. user samples dropped due to no app context available */
OPERF_BT_LOST_NO_MAPPING, /**<nr. backtrace samples dropped due to no mapping */
OPERF_LOST_INVALID_HYPERV_ADDR, /**<nr. hypervisor samples dropped due to address out-of-range */
OPERF_RECORD_LOST_SAMPLE, /**<nr. samples lost reported by perf_events kernel */

At the completion of a profiling run, these stats are written to the
operf.log file (new in this patch) at <session_dir>/samples.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-06-12 18:38:47 Tree
[6df901] by Maynard Johnson Maynard Johnson

Build operf man page only when the operf program is also built

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-06-11 19:18:52 Tree
[88e125] by Maynard Johnson Maynard Johnson

Switch operf from popt to getopt

Using popt to parse command line arguments for operf did not
work properly for cases where an application to profile is
passed in, along with some app arguments that happen to have
option names the same as operf. Therefore, operf has been
changed to use getopt_long. This decision to not use popt
negated the reason for the changes made to oprofile's libopt++
popt_option.[c|h] files back when operf was first introduced;
thus, those changes are reverted with this patch.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>

2012-06-11 15:10:58 Tree
[b036fd] by Maynard Johnson Maynard Johnson

Remove reset option from operf and replace with append option.

By default, operf will now move old profile data from <session_dir>/samples/current
to <session_dir>/samples/previous. If a 'previous' profile already existed,
it will be replaced. If the --append option is passed, old profile data is left
in place and new profile data will be added to it, and the 'previous' profile
(if one existed) will remain untouched.

operf man page updates:
Aside from replacing the --reset option with the --append option, several unrelated
fixes were made, including adding the missing --vmlinux option.

2012-05-22 13:54:38 Tree
[d77ab4] by Maynard Johnson Maynard Johnson

Make new --separate-thread option for operf

This patch reverses the earlier decision to do "separate=thread" type
of functionality by default. So now there is a command line option
to operf called "--separate-thread". I decided to make this an option
for two reasons: 1) operf run in system-wide mode required the user to
either pass a tgid spec or to use "--merge=tgid" or the report was
unreadable; 2) typically, the Java JIT compiler will spawn threads
to execute JITed code; so when using operf to profile a single Java app,
the resulting report is usually unreadable without using a tid spec or
"--merge=tid".

2012-05-03 19:21:08 Tree
[0ef7e7] by Maynard Johnson Maynard Johnson

Add support for callgraph profiling

Unlike legacy oprofile (using opcontrol), the --calllgraph
option of operf is boolean. The perf_events kernel subsystem
records the whole callstack, so there's no way to use the
depth value used in legacy oprofile.

2012-04-11 16:18:45 Tree
[b2ce90] by Maynard Johnson Maynard Johnson

Minor bug fixes and performance improvement for system-wide mode.

The operf_sfile hashing algorithm was modified from legacy hashing
to use either a build-id or a checksum. I had not yet implemented the
getting the build-id, so was falling back to the checksum. Getting
the checksum (via gelf_checksum) was terribly expensive, especially
noticeable when running with the system-wide option. So I spent
some time comparing using a build-id (obtained from the binary file's
NT_GNU_BUILD_ID note) for the hashing algorithm versus simply hashing
on a substring of the image name. The simple string hash was as
effective as the build-id method. Both were way better than the checksum
technique. In the end, I removed all of the checksum and build-id stuff,
and settled on the image name string hash method for finding operf_sfiles.

Aside from the above big performance improvement described above, I also
created a global multimap for holding operf_mmap objects. The operf_mmap
encapsulates an MMAP event. In system-wide mode, we get lots of MMAP events
for the same libraries being used by many different processes, so it was
logical to create just one operf_mmap object per unique binary.

2012-03-27 23:03:45 Tree
[46f3e3] by Maynard Johnson Maynard Johnson

Add support for system-wide profiling to libperf_events and operf

This patch makes changes in libperf_events to support the system-wide
profiling that the oprofile daemon will need to use. The patch also
adds support for the --system-wide option in operf as an initial step
to validate the functionality of libperf_events.

2012-03-22 13:49:58 Tree
[1fc65f] by Breno Leitao Breno Leitao , pushed by Maynard Johnson Maynard Johnson

Add the new operf.1.in file for the new operf man page

I neglected to do this on the previous commit. Doing so now.

2012-03-20 14:45:39 Tree
[f1a677] by Breno Leitao Breno Leitao , pushed by Maynard Johnson Maynard Johnson

New man page for operf command.

2012-03-19 14:49:40 Tree
[d29bec] by Andreas Krebbel Andreas Krebbel , pushed by Maynard Johnson Maynard Johnson

Fix up s390 implementation to match what was accepted upstream in the kernel

2011-12-13 22:06:16 Tree
Older >

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks