Oprofile usage instructions on Android

 

Oprofile usage instructions on Android

1. Purpose
This article introduces the oprofile function and describes the basic methods and steps for using oprofile Based on Android 2.1. The readers of this article are software developers and white box testers.

2. Introduction to oprofile
Oprofile is one of several evaluation and performance monitoring tools for Linux. It can work on different architectures, including IA32, IA64, AMD Athlon series, and ARM. Oprofile is included in Linux 2.5 and later kernels, and is also included in most newer Linux releases. Oprofile has been integrated into Android.

Oprofile performs function-level performance analysis (function-level profiling) on all running Code (including kernel, kernel module, library, and applications) in the system at a low cost ), trace the call information of functions that occupy a high CPU to determine which performance bottlenecks need to be optimized in the program.

Oprofile supports two sampling methods: event-based and time-based ).

Event-based sampling means that oprofile only records the number of occurrences of a specific event (such as L2 cache miss). When the preset value is reached, oprofile records the event (take a sample ). In this way, the CPU has a performance counter ).

Time-based sampling is based on the OS clock interruption mechanism of oprofile. Every clock interruption oprofile is recorded once (sample collected once) and divided into RTC mode (RTC mode, applicable to 2.2/2.4 kernels) and timer interrupt mode (timer interrupt mode, applicable to more than 2.6 kernels ). The timer sampling mode is introduced to provide support for CPU without performance counters. Its accuracy is lower than that of event-based sampling because of OS clock interruption, oprofile cannot analyze the code that disables interruption.

The Qualcomm QSD8K processor provides performance counters, but the released software version only supports the timer mode.

On Android, oprofile is divided into two parts: target and host. The target end runs on the device and mainly includes a kernel module (oprofile. ko) and a user space daemon (oprofiled). The former is responsible for accessing performance counters or registering time-based sampling functions (registered using register_timer_hook, enable the clock interrupt handler to access the program when it finally executes profile_tick), and place the sample in the kernel buffer. The latter runs in the background to collect data from the kernel space and write the file. The host runs on the PC, including a set of post-processing tools used to generate readable analysis reports from raw sample data.

3. oprofile usage
This section describes how to use oprofile Based on Android 2.1 (Eclair). The usage of oprofile is similar to that of Android 1.6 (Donut) and Android 2.2 (Froyo.

Before using oprofile, make sure that the system burned to the mobile phone has the root permission. Otherwise, the oprofile cannot be used, make sure that there is sufficient space available under/data to save the sample data (usually dozens of MB is enough ). Follow these steps.

3.1 Step 1: Install the target client
The source code of the exported oprofile is included in the Android source code, and the default configuration options of the kernel are also enabled to support the oprofile. Before installing the target end of oprofile to your mobile phone, compile the source code in eng mode and copy the required files to your mobile phone by following the steps below:

1. kernel module oprofile. ko:

Run on PC:

Source build/envsetup. sh

Choosecombo

Adb push $ ANDROID_PRODUCT_OUT/obj/KERNEL_OBJ/arch/arm/oprofile. ko/data

2. Daemon oprofiled and control program opcontrol:

If the system is burned on the phone. img is compiled in the eng mode and contains oprofiled and opcontrol (in/system/xbin/). This step can be skipped. img does not contain these two files. Run the following command:

Adb push $ ANDROID_PRODUCT_OUT/system/xbin/oprofiled/system/xbin

Adb push $ ANDROID_PRODUCT_OUT/system/xbin/opcontrol/system/xbin

3. elf kernel image file:

To profiling the kernel, copy the compressed elf kernel image file vmlinux to your mobile phone and run:

Adb push $ ANDROID_PRODUCT_OUT/obj/KERNEL_OBJ/arch/arm/boot/compressed/vmlinux/data

This vmlinux must be consistent with the kernel running on the mobile phone.

3.2 Step 2: Calculate the kernel virtual address range
To profiling the kernel, You need to calculate the start and end addresses of the kernel:

Run:

Adb pull/proc/kallsyms.

Search for _ text in the kallsyms file. The value is the kernel start address, and the value of _ etext is the kernel end address.

3.3 Step 3: Set the CPU to run at the highest frequency
To ensure the accuracy and consistency of the oprofile sampling results, you must set the CPU to run at the highest frequency before the sampling starts. Therefore, run the following command in the adb shell:

Mkdir/data/debug

Mount-t debugfs/data/debug

Echo 1>/data/debug/nohlt

Echo performance>/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

3.4 Step 4: Configure oprofile
Run the following command in the adb shell:

Insmod/data/oprofile. ko timer = 1

Opcontrol -- setup

Oprofiled -- session-dir =/data/oprofile -- vmlinux =/data/vmlinux -- kernel-range = start, end -- events = CPU_CYCLES: 255: 0: 50000: 0: 1: 1 -- separate-lib = 1 -- separate-kernel = 1

Note:

The start and end in -- kernel-range are the kernel start Addresses and kernel end addresses obtained in step 2.

3.5 Step 5: Start sampling
Run the application or scenario that requires profiling, and then run it in the adb shell:

Opcontrol -- start

In this case, oprofile has started sampling and can be run in the adb shell:

Opcontrol -- status

View the oprofile running status and number of samples collected at any time.

3.6 Step 6: Stop sampling
When the number of samples collected is large enough (thousands based on experience), run the following command in the adb shell:

Opcontrol -- stop

3.7 Step 7: Upload data and generate analysis results
Run on PC:

Source build/envsetup. sh

Choosecombo

Cp $ ANDROID_PRODUCT_OUT/obj/KERNEL_OBJ/vmlinux $ ANDROID_PRODUCT_OUT/symbols

Python $ ANDROID_BUILD_TOP/external/oprofile/opimport_pull ~ /Oprofile-result

At this time, the sampling data on the mobile phone is converted and stored on the PC ~ /Oprofile-result, run the following command to display the analysis result report:

Cd ~ /Oprofile-result

$ OPROFILE_EVENTS_DIR/bin/opreport -- session-dir =.-p $ ANDROID_PRODUCT_OUT/symbols-d-l

(Note: if an error occurs when running the preceding command in Android 2.1 (Eclair), replace opreport with the compiled version 0.9.4 opreport. For the compilation steps, see the appendix in this document .)

Note: If you encounter the following error when performing the preceding steps:

Opreport: error while loading shared libraries: libbfd-2.18.0.20080103.so: cannot open shared object file: No such file or directory

Run the following command to solve the problem:

Ln-s/usr/lib/libbfd. so/usr/lib/libbfd-2.18.0.20080103.so.

3.8 run oprofile again
Steps 1 to 7 above have completed a complete oprofile sampling and analysis process. To run oprofile again, you need to reset the oprofile and clean up the last sample data and run it in the adb shell:

Opcontrol -- shutdown

Rm/data/oprofile

Umount/data/debug

Rm-rf/data/debug

Then perform step 3 to Step 7 to perform the next collection and analysis.

4. A script to simplify the use of oprofile
From the introduction above, we can see that the use of oprofile is complicated. to simplify the use steps, you only need to follow the steps below to complete the operations of oprofile:

1. Prepare the Working Environment: ① compile the source code in eng mode; ② create a working directory for using oprofile (for example ~ /Oprofile.zip: unzips the compressed package oprofile_assist.zip to this directory and enter it. ③ obtain the kernel start address and end address according to the method described in section 3.2 above and enter op. sh; ④ ensure that the system installed on the mobile phone has the root permission, and the compiled kernel source code is consistent with the kernel actually running on the mobile phone; ⑤ ensure that choosecombo has been run;

2. Install target: connect the mobile phone and PC with a data cable and run the following command in the oprofile working directory on the PC:

./Prepare. sh

(Note: if the system is Android 1.6 (Donut), run./prepare. sh donut)

3. Sampling: run the application or scenario that requires profiling, and then run it in the adb shell:

Cd/data

Sh op. sh

You can run opcontrol -- status to view the oprofile running status and the number of samples collected. When the number of samples collected is large enough (Thousands of samples can be collected based on experience ), run the following command in the adb shell:

Opcontrol -- stop

4. Upload data: run in the oprofile working directory on the PC:

./Import. sh

5. Display Analysis Results: run the following command in the oprofile working directory on the PC:

./Report. sh

6. Run oprofile again: in the adb shell:

Cd/data

Sh opclean. sh

Then execute Steps 3 to 5.

5. oprofile analysis result instance
The following is an oprofile Analysis of an application running alpha animation on Android 2.1 (Eclair:

CPU: CPU with timer interrupt, speed 0 MHz (estimated)

Profiling through timer interrupt

TIMER: 0 |

Samples | % |

------------------

1769 98.4418 app_process

TIMER: 0 |

Samples | % |

------------------

1299 73.4313 libskia. so

386 21.8202 vmlinux

39 2.2046 libdvm. so

17 0.9610 libc. so

9 0.5088 libui. so

4 0.2261 libbinder. so

4 0.2261 libsurfaceflinger. so

4 0.2261 libutils. so

3 0.1696 libandroid_runtime.so

1 0.0565 libGLES_android.so

1 0.0565 gralloc. qsd8k. so

1 0.0565 libm. so

1 0.0565 libstdc ++. so

13 0.7234 rild

TIMER: 0 |

Samples | % |

------------------

9 69.2308 vmlinux

4 30.7692 linker

6 0.3339 vmlinux

4 0.2226 cnd

TIMER: 0 |

Samples | % |

------------------

2 50.0000 linker

1 25.0000 cnd

1 25.0000 vmlinux

2 0.1113 adbd

TIMER: 0 |

Samples | % |

------------------

2 100.000 vmlinux

1 0.0556 init

TIMER: 0 |

Samples | % |

------------------

1 100.000 vmlinux

1 0.0556 port-bridge

TIMER: 0 |

Samples | % |

------------------

1 100.000 vmlinux

1 0.0556 opcontrol

TIMER: 0 |

Samples | % |

------------------

1 100.000 vmlinux

 

Samples % image name app name symbol name

554 30.8292 libskia. so app_process S32A_Opaque_BlitRow32_neon

456 25.3756 libskia. so app_process S32A_D565_Blend_neon (unsigned short *, unsigned int const *, int, unsigned int, int, int)

128 7.1230 vmlinux app_process _ memzero

113 6.2883 libskia. so app_process memset_128_loop

78 4.3406 libskia. so app_process memset_128_loop

65 3.6171 vmlinux app_process _ fig

20 1.1130 vmlinux app_process get_page_from_freelist

18 1.0017 libskia. so app_process Sprite_D32_S32: blitRect (int, int)

17 0.9460 vmlinux app_process v7wbi_flush_user_tlb_range

16 0.8904 vmlinux app_process free_hot_cold_page

15 0.8347 libskia. so app_process Sprite_D16_S32_BlitRowProc: blitRect (int, int)

13 0.7234 vmlinux app_process _ spin_unlock_irq

12 0.6678 libdvm. so app_process dalvik_inst

12 0.6678 libskia. so app_process SkDraw: drawPaint (SkPaint const &) const

11 0.6121 vmlinux app_process _ dabt_usr

11 0.6121 vmlinux app_process v7_dma_flush_range

10 0.5565 libskia. so app_process S32A_D565_Opaque_Dither (unsigned short *, unsigned int const *, int, unsigned int, int, int)

...

From the above results, we can see that DURING alpha animation running, the 2D graphics library libskia is used in the oprofile sampling data. so accounts for the highest proportion, up to 73.4313%, specifically libskia. the functions S32A_Opaque_BlitRow32_neon and S32A_D565_Blend_neon in so account for the top two, respectively. This shows that the most performance-impact bottleneck in this process is the functions in the skia library.

Appendix precautions for using oprofile on Android 1.6 (Donut)
The opimport and opreport (in $ OPROFILE_EVENTS_DIR/bin/) Self-contained in Android 1.6 (Donut) are 64-bit and can only be run on a PC with a 64-bit Linux system installed, to run on a 32-bit PC, you can compile the opimport and opreport versions 0.9.4 by yourself (because the oprofile in Android 1.6 (Donut) is 0.9.4 ). 0.9.4 oprofile source code is attached to the following: (omitted)

 

The compilation procedure is as follows:

Source build/envsetup. sh

Choosecombo

Tar-zxvf oprofile-0.9.4.tar.gz

Cd oprofile-0.9.4

./Configure -- with-linux = $ ANDROID_PRODUCT_OUT/obj/KERNEL_OBJ

Make

Make install

Alternatively, you can use the opimport and opreport (version 0.9.5) in Android 2.1 or later versions.

In addition, the script $ ANDROID_BUILD_TOP/external/oprofile/opimport_pull in Android 1.6 (Donut) has a problem and can be replaced with this file in Android 2.1 (Eclair) or later versions.
Author: confused