使用ARM DS-5与Dstream StreamLine进行Android底层性能分析的一个实例

前言

一个类似于Android的OS,只使用了BT机能的状态下,CPU的占有率超过20%,于是我们想看看是什么原因。本篇文章注意介绍了使用Dstream StreamLine来进行性能分析的过程和实例以及可能需要注意的地方。

StreamLine准备

使用StreamLine来分析性能主要包含以下几个过程

  1. 配置内核使得内核可以产生一些性能相关的数据,以及一些设施用以支持gator,例如:高精度的timer(hr_timer)
  2. 安装gator模块,用于系统性能数据(scheduler,event,Process)的采集以及对这些数据进行注释(annotate),例如对CP15中的PMNC(Performance Monitor Control Register)寄存器的读取与配置,对调度器数据的采集
  3. gatord从gator内核模块中获取性能数据,并通过网络(不一定是网线)传递给Host PC中的DS-5
  4. DS-5中的streamline对应软件模块对性能数据进行分析,以及与模块代码做出对应

对于前面的第一、第二步骤可以参考ARM官方的说明文档:ARM Streamline

编译与环境准备时候的注意点

如果使用的是adb 来让gatord传输数据到Host PC,那么需要将其中gator kernel module中的宏去掉(注释掉):

If you are building for an Android target, you must remove the comment hashtag from the following line in the makefile of the gator module to enable kernel stack unwinding

# EXTRA_CFLAGS += -DGATOR_KERNEL_STACK_UNWINDING

StreamLine数据采集与配置

gatord 端口号被占用问题

默认情况下,gatord使用的端口号为8080,但是在运行了许多应用程序的OS中,有可能这个端口号已经被占用了,如果被占用了,那么gatord在运行的时候,会出现如下的log提示,询问我们是否已经运行了一个gatord实例了:

Is an instance already running?

此时,我们可以使用ps 来查看一下是否已经存在运行的gatord,如果没有,那么可以看看这个端口号被谁使用了:

lsof  | grep 8080

如果没有lsof(android),那么可以使用netstat来查看:

 netstat -ltpn | grep 8080

另外也可以修改代码,打印出提示log对应的errno,在gator-daemon中的main.cpp中,添加errno的头文件,在bind IP地址失败后打印出errno来。

如果确实被占用了,那么我们需要更改这个端口号,可以直接对main.cpp中的端口号8080进行更改,也可以在运行gatord的时候,使用-p选项进行指定,例如将端口号指定为8888:

gatord -p 8888&

使用USB-ADB来连接Target与Host

如果没有网线,但是有adb(在android手机中,几乎都有),那么就可以使用adb

在PC中将远程gatord的端口号转发到本地的某个端口号,例如也是8888:

adb forward tcp:8888 tcp:8888

性能数据的采集

从DS-5 Eclipse中选择Window > Show View > Other > DS-5 > ARM Streamline Data
然后点击齿轮配置Capture。
因为已经使用adb将远程的gatord输出重定向了本地PC上的8888端口,所以在Address中填入localhost:8888。最后面的Program Images可以添加elf文件,从而可以加载symbols。添加elf image文件,也可以在采集完成后再添加。这里以采集完成后添加为例。
 

添加少量的elf文件用于分析

在完成了Capture以后,可以添加elf文件,从而使各个进程都有symbols,点击下图中的齿轮,进入配置页面。
 
Figure: Setting

在弹出的设置对话框中,在Program Images中可以添加elf文件,但是这里只能一个个的添加,无法大量按照特殊要求添加(例如只添加libQt***):

Figure: Add_ELF_Files

添加大量的elf文件用于分析

如果要添加大量的elf文件,或者要按照我们特别的需求来添加大量的elf文件,那么就需要其他方法。

从前面的Figure: Setting图中,方框标明了这个Capture文件的位置:

/home/hexiongjun/Documents/Streamline/Test.apc/ , 其中添加了的elf文件记录在session.xml文件中。
打开这个Capture session的session.xml,添加所有的so和vmlinux文件路径,例如添加了几个的样子:













session.xml (END)

注意红色字体的部分,就是添加了的几个文件。同时注意这些elf文件的路径位置,它们被拷贝到了/home/hexiongjun/Documents/Streamline/Test.apc/中。

因此,现在问题就转换成了在session.xml文件中按照格式添加文件列表了。对于需要添加的的文件我们假设有两种:

  1. 添加所有elf的文件:内核+OS+App
  2. 只添加符号某一类条件的文件:例如libQt***

添加所有elf的文件

为了表示最极端的情况,这里假设需要将所有的OS相关elf文件、以及APP elf文件都添加进来。那么其实就是:

  • kernel相关:vmlinux + kernel modules(ko)
  • Application相关:可执行的应用程序,应用程序依赖的shared objects,以及so依赖的so

对于前者,直接添加即可,如果kernel module比较多,那么可以直接在kernel module_install中find一把,然后重定向到一个文件中,即可得到所有的ko文件路径列表。

对于后者,需要根据实际情况来处理,如果是Android环境下,那么所有的没有strip过的elf文件都放在:

out/target/$TARGETPRODUCT/symbols

$OUT/symbols

然后,使用find命令以及realpath命令来获取这些文件路径,然后拷贝到session.xml中,并使用编译器或者sed/awk,让这些文件列表符合xml语言语法接口,例如在VIM中可以使用下面命令来添加每行的结束字符串"/>:

:%s/$/\"\/\>

只添加符号某一类条件的文件

要包含某一类的lib,可以使用realpath:

realpath all_libs/libQt* >> ../list.txt
realpath all_libs/libqt* >> ../list.txt

StreamLine采集数据的分析

在添加好elf image文件之后,就可以双击采集好的session来进行分析了,但是如果添加的文件比较多,有可能会出现如下的提示:

java heap space

对于此问题,可以参考我在ARM社区的提问:How to solve the Java heap space when streamline analyse the capture?

分析完成后,可以在Timeline标签中看到各个Process的CPU占有率。如下图中,bt线程使用了21.3%的CPU:

然后我们需要找到都是那些函数占用的CPU,切换到Call Paths标签可以看到:

出于隐私等因素,对函数和线程名称进行了模糊处理,但是CPU主要用于了串口通讯。然后根据我们的代码和对串口的使用方法知道我们没有使用DMA来传输数据,而BT本身有大量的数据产生。因此修改代码使用DMA来传输数据,然后对比CPU的占用率,就知道是否是这里的问题了。


参考

捕鱼达人用的游戏引擎cocos2d-x使用StreamLine的优化实例

Streamline profiler: Revealing reality

Software Optimization: Four real-life Streamline use cases


如果文章有格式问题,请移步:http://www.hexiongjun.com/?p=187

转载请注明出处。作者:TonyHo hexiongjun.com 

你可能感兴趣的:(ARM)