Commit [a39d41]  Maximize  Restore  History

Fix holes in operf system-wide profiling of forked processes

Using operf to do system-wide profiling of the specjbb benchmark
exposed some holes in how operf was processing the perf_events
data coming from the kernel. Some of the events we can get from
the kernel are:

The "COMM" event is to notify us of the start of an executable
application. The "FORK" event tells us when a process forks
another process. The "MMAP" event informs us when a shared library
(or executable anonymous memory, or the executable file itself, etc.)
has been mmap'ed into a process's address space. A "SAMPLE"
event occurs each time the kernel takes a sample for a process.

There is no guarantee in what order these events may arrive from
the kernel, and when a large system (say, 64 CPUs) is running
the specjbb benchmark full bore, with all processors pegged to
100%, you can get some very strange out-of-order looking
sequence of events. Things get even stranger when using Java7
versus Java6 since Java7 spawns many more threads.

The operf code had several issues where such out-of-order
events were not handled properly, so some major changes were
required in the code.

Signed-off-by: Maynard Johnson <>

Maynard Johnson Maynard Johnson 2013-04-25

changed libperf_events/operf_process_info.cpp
changed libperf_events/operf_process_info.h
changed libperf_events/operf_utils.cpp
libperf_events/operf_process_info.cpp Diff Switch to side-by-side view
libperf_events/operf_process_info.h Diff Switch to side-by-side view
libperf_events/operf_utils.cpp Diff Switch to side-by-side view

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

Sign up for the SourceForge newsletter:

No, thanks