From: Arlie S. <ar...@wo...> - 2013-02-13 19:36:40
|
Hi Folks, A lot of people at my company love oprofile, but we've been running 0.9.6. Now we have some of our products using a processor from the Sandy Bridge family, which means that we need oprofile 0.9.7 at least. Those products are running on a 2.6.32 kernel. I've been trying to build 0.9.7 and 0.9.8 from source, determine which to use and how to get it into our build environment. (The target is an embedded system.) I'm not doing too well ;-) so I hope you folks can help. Given that I'm having issues with both builds/installs, perhaps the first thing I'd like advice with is deciding which one to use. - there seem to be a lot of issues with the 0.9.8 framework, and more on older kernels - but generally I'd rather jump as far as possible when we upgrade, so we won't be doing this again any time soon - the people here are used to what's now legacy mode (opcontrol), and are generally interested in whole system performance; they also have access to root - so overall not much need for operf - I'm particularly worried about the lost record problem in 0.9.8, but I'm not really sure how much it would bother the folks using the tool - Having operf not work for root while working for other users would also probably cause a lot of confusion (particularly as the failure mode is apparant sucecss but no samples collected) What do you folks think? 0.9.7 or 0.9.8? Thanks, -- Arlie (Arlie Stephens ar...@wo...) |
From: Robert R. <rr...@ke...> - 2013-02-13 20:04:42
|
On 13.02.13 11:42:57, Arlie Stephens wrote: > A lot of people at my company love oprofile, but we've been running 0.9.6. > Now we have some of our products using a processor from the Sandy > Bridge family, which means that we need oprofile 0.9.7 at least. Those > products are running on a 2.6.32 kernel. Your kernel needs to detect your cpu. Which model number shows /proc/cpuinfo? What is the detected cpu_type? This should tell you: # mount -t oprofilefs nodev /dev/oprofile # cat /dev/oprofile/cpu_type # umount /dev/oprofile -Robert |
From: Robert R. <rr...@ke...> - 2013-02-13 20:13:08
|
On 13.02.13 21:04:21, Robert Richter wrote: > On 13.02.13 11:42:57, Arlie Stephens wrote: > > A lot of people at my company love oprofile, but we've been running 0.9.6. > > Now we have some of our products using a processor from the Sandy > > Bridge family, which means that we need oprofile 0.9.7 at least. Those > > products are running on a 2.6.32 kernel. > > Your kernel needs to detect your cpu. Which model number shows > /proc/cpuinfo? > > What is the detected cpu_type? This should tell you: > > # mount -t oprofilefs nodev /dev/oprofile > # cat /dev/oprofile/cpu_type > # umount /dev/oprofile This one is a bit easier: # opcontrol --init; echo $(cat /dev/oprofile/cpu_type ); opcontrol --deinit -Robert |
From: Arlie S. <ar...@wo...> - 2013-02-13 22:28:24
|
On Feb 13 2013, Robert Richter wrote: > > On 13.02.13 11:42:57, Arlie Stephens wrote: > > A lot of people at my company love oprofile, but we've been running 0.9.6. > > Now we have some of our products using a processor from the Sandy > > Bridge family, which means that we need oprofile 0.9.7 at least. Those > > products are running on a 2.6.32 kernel. > > Your kernel needs to detect your cpu. Which model number shows > /proc/cpuinfo? processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-4650 0 @ 2.70GHz stepping : 7 cpu MHz : 2700.216 cache size : 20480 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes > > What is the detected cpu_type? This should tell you: > > # mount -t oprofilefs nodev /dev/oprofile > # cat /dev/oprofile/cpu_type > # umount /dev/oprofile # cat /dev/oprofile/cpu_type i386/arch_perfmon > > -Robert -- Arlie (Arlie Stephens ar...@wo...) |
From: Robert R. <rr...@ke...> - 2013-02-14 11:12:34
|
On 13.02.13 14:34:40, Arlie Stephens wrote: > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 45 > model name : Intel(R) Xeon(R) CPU E5-4650 0 @ 2.70GHz > stepping : 7 > cpu MHz : 2700.216 > cache size : 20480 KB > physical id : 0 > siblings : 8 > core id : 0 > cpu cores : 8 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 13 > wp : yes > # cat /dev/oprofile/cpu_type > i386/arch_perfmon This is fine. Sandybridge is detected in userland. You need at least oprofile 0.9.7. -Robert |
From: Maynard J. <may...@us...> - 2013-02-14 15:59:38
|
On 02/13/2013 01:42 PM, Arlie Stephens wrote: > Hi Folks, > > A lot of people at my company love oprofile, Thanks for the love! > but we've been running 0.9.6. > Now we have some of our products using a processor from the Sandy > Bridge family, which means that we need oprofile 0.9.7 at least. Those > products are running on a 2.6.32 kernel. Several Linux distributions I'm aware of (e.g., SLES 11 SP1(+) and RHEL 6(+)) use 2.6.32 as a base. Technically, this kernel version meets the requirement to build OProfile's operf tool, which requires the Linux Kernel Performance Events Subsystem (aka "perf_events", introduced in 2.6.31). But the perf_events subsystem underwent a lot changes and bug fixes through subsequent kernel releases. Linux distributors typically backport important upstream kernel fixes into their base kernel, but the timing of a release means that one distro's 2.6.32-based release may have more fixes than another distro's 2.6.32-based release -- and, of course, this is also true within a given distro insofar as its service packs/updates. 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. > > I've been trying to build 0.9.7 and 0.9.8 from source, determine which > to use and how to get it into our build environment. (The target is an > embedded system.) I'm not doing too well ;-) so I hope you folks can > help. We're here to help! Let us know the specifics of your build issues. But, please, use either the official 0.9.8 release or event a current git pull. Many critical bug fixes were made available in 0.9.8 (see http://oprofile.sourceforge.net/release-notes/oprofile-0.9.8), and you don't want to be debugging problems that have already been fixed. Also, if you run into a situation where a fix is needed, we'll be making that fix against current git sources -- i.e. not backporting to 0.9.7. Your chances that are better for new fixes to apply cleanly to 0.9.8 than to 0.9.7. 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. -Maynard > > Given that I'm having issues with both builds/installs, perhaps the > first thing I'd like advice with is deciding which one to use. > > - there seem to be a lot of issues with the 0.9.8 framework, and more > on older kernels > - but generally I'd rather jump as far as possible when we upgrade, so > we won't be doing this again any time soon > - the people here are used to what's now legacy mode (opcontrol), and > are generally interested in whole system performance; they also have > access to root - so overall not much need for operf > - I'm particularly worried about the lost record problem in 0.9.8, but > I'm not really sure how much it would bother the folks using the tool > - Having operf not work for root while working for other users would > also probably cause a lot of confusion (particularly as the failure > mode is apparant sucecss but no samples collected) > > What do you folks think? 0.9.7 or 0.9.8? > > Thanks, > > -- > Arlie > > (Arlie Stephens > ar...@wo...) > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: Arlie S. <ar...@wo...> - 2013-02-14 23:23:26
|
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. 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 (Arlie Stephens ar...@wo...) |
From: Maynard J. <may...@us...> - 2013-02-15 14:44:07
|
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 PERF_EVENT_H="$KERNELDIR/include/linux/perf_event.h" fi AC_CHECK_HEADER($PERF_EVENT_H,PERF_EVENT_H_EXISTS="yes") +PERF_EVENT_H_EXISTS= AM_CONDITIONAL(BUILD_FOR_PERF_EVENT, test -n "$PERF_EVENT_H_EXISTS") if test "$PERF_EVENT_H_EXISTS" = "yes"; then HAVE_PERF_EVENTS='1' -------------------------------------- -Maynard > > 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 > > (Arlie Stephens ar...@wo...) > |