Home
Installing Performance Inspector ™ for Linux
Supported systems
- Performance Inspector works with x86, x86_64, ppc64, and s390 architectures.
- This package has been tested with SLES 9, 10, and 11, RHEL 4 and 5, and Ubuntu 10.04 (32-bit)
- The lowest kernel version we tested with: 2.6.5
- The highest kernel version we tested with: 2.6.32
- Note that we did not test all possible OS/arch combinations, please let us know if something is not working on your system.
- On ppc64, there is no support for virtualized per thread metrics (ptt), except cycles (work in progress).
- On s390, there is no support for ptt.
Prerequisites
Performance Inspector is designed to work without the need to patch
the kernel source code. Instead, it builds a kernel module compiled against
the currently running kernel. This module takes advantage of the same system hooks used
by OProfile, so we can be notified on timer ticks, task exit and memory unmap.
For Dispatch hooks and ITrace, we use kprobes (ppc64) or run-time kernel patching (x86, x86_64).
You need the following prerequisites to compile and run Performance Inspector:
- Kernel source.
-
On many Linux systems it is not necessary to explicitly install the kernel source to build external kernel modules.
Enough of the source is automatically included in /lib/modules/$(uname
-r).
- Some distributions separate the source, by making /lib/modules/$(uname -r)/source a symbolic link to
/usr/src/linux, so you need to install the appropriate rpm with the kernel source if not already installed.
- On RHEL4/RHEL5, you need kernel-devel-2.6.x.EL or kernel-smp-devel-2.6.x.EL (RHEL4, smp) rpm (where x matches your version number).
- On SLES, you need kernel-source-2.6.x rpm (where x matches your version number).
- You also need a valid /boot/System.map or /boot/System.map-kernel-name.
We use System.map to get kernel symbols which are not exported.
- binutils
- We use libbfd.so during the trace post processing to get module information, and libopcodes.so to get assembly instructions.
- Both libraries are components of the binutils package, which is usually included in Linux distrubutions.
- On RHEL5 and other newer distributions, you also need to install the binutils-devel package, to get binutils header files.
- JDK
- If you are building the tools using the tarball, you need Java and some JVMPI/JVMTI header files, usually part of JDK installation.
- You can enter the name of the JDKDIR during installation,
or add it to the path
- Example: export PATH=${JAVAHOME}/bin:${JAVAHOME}/jre/bin:$PATH, where ${JAVAHOME} has an include directory
- kprobes
- Needed for ptt and task dispatch tracing.
- Not needed for x86, x86_64
- Needed for ppc64 - if running on a system without kprobes and want ptt, you need to rebuild your kernel.
- Not applicable for s390 (no ptt support).
- Other
- With SLES 10 on 64-bit platforms, to compile both 32-bit and 64-bit libraries you need glibc-devel rpms for 32 and 64 bit.
If you get an error message about missing stubs-32.h, you need to install the 32-bit glibc-devel. If you get an error message about missing stubs-64.h, you need the 64-bit glibc-devel.
Installation using the tarball
- Make sure you have a softlink (or directory) to /usr/src/linux that matches
your kernel (See Prerequisites).
- Make sure you have a libbfd.so (See Prerequisites).
- Download the complete source tarball pi_linux_src-20100715.tar.gz
-
Untar package:
tar -xzf pi_linux_src-20100715.tar.gz
cd Dpiperf
-
From Dpiperf directory, run
./tinstall.appl
This will build and install user space tools. You will be asked for JDK directory if not in the path.
-
Change to root (su) and from Dpiperf directory run
./tinstall.drv
This will build, install, and load the kernel driver.
Setting up the environment
- In each terminal window for which you want tools access, "source" the script that
sets up your environment and ensures the kernel driver module is loaded
(note the dot, blank in front of the setrunenv command).
cd tools_dir/Dpiperf/bin
. ./setrunenv
- You need to be the root user or su to load the kernel driver.
- Note that you need to load the driver only once - it stays loaded until unloaded (using pi_unload.sh script from Dpiperf/bin),
or until the system is rebooted, so you need to be root/su only for the first execution of setrunenv.
- If you do not like the error messages when running setrunenv as a regular user, you can use the option nodrvload
(. ./setrunenv nodrvload)
- If you want to profile a Java application which is not started from a command line, you need to copy libjprof and libperfutil to
a system library directory (such as /usr/lib or /usr/lib64 for 64-bit apps), or to create the corresponding symlinks.
A warning about ITrace
DO NOT RUN ITRACE WITHOUT A BACKUP,
Since ITrace can hang your system.
In the current package on x86 and x86_64 systems, ITrace run-time patches stay in the kernel
until the computer is rebooted, so do not manually unload the driver after collecting an ITrace.
On PPC64, ITrace support can be safely removed by unloading the driver.
Known Problems
- No counter support for Xen (counters are not virtualized).
- No graceful failure if two PttInit() calls follow one another, with different metrics
(e.g., running two instances of Java with jprof at the same time, one with ptt_cycles and another with ptt_insts).
- OProfile cannot be run with the Performance Inspector driver loaded.
- Per-thread metric implementation messes up applications such as top; you cannot run top and ptt at the same time.
- run.tprof in continuous mode (default) may occasionally hang the system with 16 or more CPUs.
- run.tprof on RHEL sometimes does not produce trace records, it may work OK after reboot or you may use NONHALTED_CYCLES (fix is work in progress).
- You need to reboot the system to completely get rid of ITrace on x86, x86_64; it may occasionally hang during reboot.
- ITrace on PowerPC may occasionally hang the system (especially single-step ITrace).
- Time-based tprof may not give correct idle time percentage with kernel preemption enabled or dynamic ticks
Home