On 02/14/2013 05:29 PM, Arlie Stephens wrote:
> On Feb 14 2013, Maynard Johnson wrote:
>> On 02/13/2013 01:42 PM, Arlie Stephens wrote:
>> For the
>> above-mentioned Linux distros, my experience has been that SLES 11
>> SP2 and RHEL 6.2 have adequate perf_events support to allow operf to
>> be fully functionaly.
> We're based on Scientific Linux 6.1, which appears to be based on RHEL
> 6.1. This suggests that I shouldn't be trying to use operf, unless I
> want to go hunting for needed patches.
>> We're here to help! Let us know the specifics of your build issues.
> So far, most of my issues have turned out to be problems with
> configure's user interface.
> It turns out that if you are going to specify --with-kernel, the
> syntax is a bit finicky.
> - The argument to --with-kernel must not be specified as a relative
> path, because configure will apparantly cd to some other directory
> before using the exact path specified. It then cannot find perf_event.h
> - if you try to use get-opt style syntax (--with-kernel /foo rather
> than --with-kernel=/foo) the resulting error messages are unclear
> I imagine this is obvious to people who've had more experience with configure.
> My other problem has been not fully understanding how the pieces go
> together. I think I have most of it now, but perhaps I had better
> reality check with you folks.
> Legacy (opcontrol) mode:
> - kernel part comes with any kernel from 2.6 forward, and is called
> the oprofile driver. The pieces can be found in the kernel tree in
> directories like arch/*/oprofile/ and drivers/oprofile.
> - user space pieces can be found in the oprofile source tarball, but
> some of the stuff there is just for the new mode. Things needed in
> legacy mode include opcontrol, /usr/lib/oprofile, and
> /usr/bin/oprofiled, but not operf.
> Operf mode:
> - kernel part comes from the kernel events subsystem, also available
> in a kernel source tree near you, but less than adequately baked at
> RHEL 6.1s version of kernel 2.6.32.
> - user space pieces (also from the oprofile source tar ball) include
> operf, and I'm not sure what else.
>> Users can continue to use the opcontrol-based profiler with 0.9.8
>> (even though the runtime message discourages its use in preference
>> to operf). But be aware that 1) opcontrol will go away in some
>> future release; and 2) the oprofile kernel driver code is basically
>> in maintenance mode, so the focus from the kernel community is much
>> more on the perf_events code.
> From what I see in the 0.9.8 release notes, operf doesn't have feature
> parity with opcontrol, and has flakiness when recording multiple
> events, as well as issues with being run as root. Given the number of
> scripts and recipes we have that use opcontrol, and the state of our
> kernel events subsystem source, I think my best bet is to just leave
> operf off of our systems, along with anything else only needed in
> operf mode.
There are only a couple of pieces that are specific to operf, but the easiest thing is for you to do a "legacy-only" build. You could do this by applying the following patch to a clean oprofile 0.9.8 source tree. After applying the patch, be sure to run oprofile's autogen.sh script to regenerate the configure script:
--- oprofile-0.9.8/configure.ac 2012-08-27 13:59:13.000000000 -0500
+++ oprof-0.9.8-no_operf/configure.ac 2013-02-15 08:31:04.918080536 -0600
@@ -89,6 +89,7 @@ else
AM_CONDITIONAL(BUILD_FOR_PERF_EVENT, test -n "$PERF_EVENT_H_EXISTS")
if test "$PERF_EVENT_H_EXISTS" = "yes"; then
> This may bite us later, when we have to move forward and opcontrol is
> no longer supported, but that's a bridge to be crossed only when we
> need to.
> (Arlie Stephens arlie@...)