Systemtap
From OMAPpedia
Contents |
[edit] Targeted Audience
- This page provides all the necessary details to enable systemtap on OMAP platforms (Android or Poky).
- The information given below is the result of the integration on OMAP platform (ARM) of systemtap rel 1.0 with linux kernel rel 2.6.27 (and later releases)
[edit] Systemtap Documentation
- [1] SystemTap: Instrumenting the Linux Kernel for Analyzing Performance and Functional Problems
- [2] Systemtap language reference
[edit] Systemtap Source Code
- [3] links to systemtap GIT or HTTP or FTP
[edit] OMAP Systemtap Scripts/Tapsets
- [4] OMAP tapsets and scripts releases (available soon)
[edit] Systemtap and Cross Compilation
- As shown in the figure systemtap execution consists in several phases:
Systemtap & cross compilation
- 1. Script translation in C code
- 2. C code build
- 3. * .ko module build
- 4. The load and execution of the *.ko module
- Originally, systemtap was designed so that all 4 steps take place on the same system (for eg Ubuntu PC). Indeed, the system translating/building the scripts was also the one whose performance had to be analyzed.
- For embedded systems, the 4 steps are shared between a host platform (Ubuntu or other linux based environment) and the target platform (OMAP ARM).
- To use systemtap for embedded systems, the HOST system shall now support:
- 1. Script translation in C code
- 2. C code build
- 3. *.ko module build
- These 3 steps are performed by the stap command execution on the host platform.
- On the other hand, the target platform shall support:
- 4. The load and execution of the *.ko module
- This 4th step is performed by the staprun command execution on the target platform under analysis.
- Naturally, the *.ko module(s) shall be copied from the HOST to the TARGET platform between step 3 and step 4.
- It may be worth noting that once step 3 is completed and *.ko files are transferred, step 4 execution and completion solely relies on the TARGET platform; the HOST platform is not needed anymore
[edit] Systemtap Install
[edit] Pre-requisite
- In order to compile the tool and scripts, elfutils package shall be available on the host.
- elfutils 0.143 package can be downloaded from following location [5]
- No need to install elfutils on the host; only the untar'ed file is required.
- For the compilation examples given below, elfutils was untar'ed on the host root directory
- Therefore, elfutils path on the system taken as an example in this wiki page is /elfutils-0.143
[edit] Kernel Code
To run, systemtap requires the activation of the following kernel compilation flags:
- CONFIG_DEBUG_FS
- CONFIG_KPROBES
- CONFIG_DEBUG_INFO
- CONFIG_RELAY
- CONFIG_PROFILING (General setup à Profiling experimental and Oprofile system profiling)
- CONFIG_TRACEPOINTS (via CONFIG_SLAB)
To do so, it is suggested to modify the kernel settings directly accessing menuconfig (make ARCH=arm menuconfig)
Furthermore, before launching the kernel compilation, one kernel file shall be updated so that systemtap release 1.0 works for ARM architecture.
The file is ptrace.h located in kernel/arch/arm/include/asm/ directory
#define interrupts_enabled(regs) \
(!((regs)->ARM_cpsr & PSR_I_BIT))
#define fast_interrupts_enabled(regs) \
(!((regs)->ARM_cpsr & PSR_F_BIT))
++ #define condition_codes(regs) \
++ ((regs)->ARM_cpsr & (PSR_V_BIT|PSR_C_BIT|PSR_Z_BIT|PSR_N_BIT))
/* Are the current registers suitable for user mode?
* (used to maintain security in signal handlers)
*/
- Once the extra lines are added, the kernel shall be recompiled as per the OMAP release build instructions.
[edit] Systemtap 1.0 code update for OMAP ARM platforms
Following patches are required to make the tool operate properly:
[edit] Systemtap compilation for the host
- To compile systemtap executable used on the host side, proceed as follows:
./configure --exec-prefix=/systemtap-1.0-ubuntu --prefix=/systemtap-1.0-ubuntu --with-elfutils=/elfutils-macharm/elfutils-0.143 make install
- /systemtap-1.0-ubuntu will then be the default directory where executables will be generated.
[edit] Systemtap compilation for the target
- In order to compile the executable run on the target side (staprun), proceed with the following commands:
ac_cv_file__usr_include_nspr=no ac_cv_file__usr_include_nspr4=no ac_cv_file__usr_include_nss=no ac_cv_file__usr_include_nss3=no ac_cv_func_malloc_0_nonnull=yes ./configure --exec-prefix=/systemtap-1.0-macharm --prefix=/systemtap-1.0-macharm --host=arm-none-linux-gnueabi CXXFLAGS=-static CFLAGS=-static --disable-translator --disable-docs --disable-refdocs --disable-grapher --without-rpm --with-elfutils=/elfutils-arm/elfutils-0.143 make install
- In the example above, the directory containing the target executable will then be /systemtap-1.0-macharm
[edit] Systemtap installation on the target
- The two previous steps consisted in generating systemtap executables for the host and the target.
- The code generated for the host shall remain where it is generated, whereas the tool directory generated for the target (/systemtap-1.0-macharm) shall by definition be transferred to the target.
- One shall pay attention that the paths indicated for the tool compilation remain hard coded. In the example above, the tool running on the target is generated in a directory called /systemtap-1.0-macharm. It is important to keep the directory directory location and structure on the target or the tool will not solve all its code dependencies.
- Next, by default, staprun program looks for *.ko modules in the /lib/modules/xxx/systemtap directory, where xxx is related to your kernel. To get xxx, simply execute "staprun xyz" on the target, and an error will be displayed indicating the right path as:
- "ERROR: Unable to canonicalize path "/lib/modules/2.6.29-omap1-00034-g8b1c197-dirty/systemtap/xyz.ko": No such file or directory"
- This directory shall be created on your system. This is the repository where *.ko modules built on the host side shall be copied/transferred.
- On the target under /lib/modules/<kernel label>,
- create a folder systemtap
- copy the script compiled .ko located in /systemtap-1.0-ubuntu/bin in this folder.
- (The rights on the folder /systemtap-1.0-ubuntu/bin may also have to be modified using chmod 777)
- Please note that symbolic links to another local directory containing the .ko files can also be defined.
[edit] Systemtap Scripts compilation
- Scripts compilation is performed through the command below:
./stap -gv -a arm -D OMAP_REL_FAMILY -B CROSS_COMPILE=arm-none-linux-gnueabi- -r FULLKERNELPATH -I FULLTAPSETPATH -R SYSTEMTAPCFILEPATH -m SYSTEMTAPMODULENAME SCRIPTNAME
- Where:
- OMAP_REL_FAMILY is the OMAP release family (OMAP_L23, OMAP_L24, OMAP_L25).
- This field constitutes a TAG that may be used to selectively interpret/compile sections of scripts/tapsets depending on the SW release family (platform but also OS).
- FULLKERNELPATH is the Kernel full path
- FULLTAPSETPATH is the reference tapset path
- SYSTEMTAPCFILEPATH is the path to systemtap runtime directory
- SYSTEMTAPMODULENAME is the name of the output module to be generated
- SCRIPTNAME is the script file (stp file)
- On L25, typically a command example could be (from dir /systemtap-1.0-ubuntu/bin):
./stap -gv -a arm –D OMAP_L25 -B CROSS_COMPILE=arm-none-linux-gnueabi- -r custom_path/mydroid/kernel/android-2.6.29 -I /systemtap-1.0-macharm/share/systemtap/tapset -R /systemtap-1.0-macharm/share/systemtap/runtime -m contextswitch /systemtap-1.0-macharm/share/systemtap/tapset/OMAP/contextswitch.stp
- When completed, the command generates the *.ko file in the current directory.
- Additional compilation debug information can be accessed by adding several “v” in the compilation command (-gvvv for eg)
- As explained earlier, the script file is translated into a C file prior to compilation. All files generated during these steps can be accessed in a temporary directory (location given during the compilation phase), providing the –k option is applied (-gvk considering the example above)
[edit] Systemtap Scripts Execution
- To execute scripts on your platform, it is suggested to first update your PATH with the /systemtap-1.0-macharm/bin directory.
- Then any scripts previously transfered to /lib/modules/<kernel label>/systemtap directory the can be executed by invoking the staprun command as follows:
staprun contextswitch
- Where context-switch is the name of one of the .ko files contained in /lib/modules/<kernel label>/systemtap directory
[edit] Hints on systemtap for embedded platforms
[edit] Mounting RAM file system
- Although the tool by default generates the traces on the open terminal, these traces can be redirected to the filesystem (-o option when invoking staprun).
- However, experience has shown that these accesses to the filesystem could interfere with the assessment of the performance indicators gravitating around the filesystem (MMC card access for eg if filesystem is mounted onto an SD card).
- Therefore, to alleviate the interference caused by the tool accesses to the filesystem, it is suggested to mount a filesystem onto the RAM as explained below. When redirected to the filesystem mounted onto the RAM, systemtap traces output will not interference with the typical MMC activity running on the platform.
- Quick instructions:
- Create a mount point, e.g. ‘mkdir /mnt/tmp’
- Mount the RAM disk: ‘mount -t tmpfs tmpfs /mnt/tmp’
- Optionally, you can add ‘-o size=32m’ to specify the maximum size reserved for this ‘disk’
- Run systemtap scripts typing: staprun –o /mnt/tmp/output-trace.txt …
[edit] Time measurements
- By default, today on ARM architecture, the only references to time measurement are the gettimeofday_s(), gettimeofday_ms() functions.
- Indeed, the default implementation of get_cycle() function can not report any cycle counter value.
- In order to read the 32k clock value on OMAP3430/3630/4430 platforms, a function has been implemented and is defined in the reference script file omap_timestamp.stp: get_32k() [9]
- This function can be called in any other functions/probes to provide a time resolution of ~ 30µs.
- This resolution can be later on improved if needed by developing a function accessing a system timer running at a higher frequency.
