用LTT调优Bluetooth模块的一次尝试

用LTT调优Bluetooth模块的一次尝试
1 目标
基本的目标是通过LTT观察Bluetooth模块做大批量数据传输时的系统运行情况，争取找到一些影响系统性能的因素，加以优化，以提高BT模块的性能，降低CPU占用率

2 数据采集方案
基本框架是：
Ø 打开内核LTT Trace选项
Ø 将LTT Trace的主模块做为模块编译插入
Ø 选用蓝牙OBEX_FTP传输功能和A2DP做为性能数据的采集对象
Ø 在启动相关模块后使用默认参数调用LTT的tracedaemon，将trace的output文件定向到处于内存中的/tmp目录下，以加快写output文件的速度，尽可能减小trace对系统性能的影响和干扰。
Ø 完成典型的功能操作（文件传输 / 播放立体声音乐）后关闭tracedaemon。

3 起始数据的采集和分析
使用Obex_FTP与PC连接，传送一个600K左右的文件。采集的数据如下图所示：



3.1 数据分析
仔细分析数据发现，在数据采集的22.8秒的时间内，蓝牙的主进程，一共产生了133997次的系统调用，其中gettimeofday系统调用一共发生了129275次，耗时1657毫秒。这个系统调用的频率出奇的高。
如上图中所示前半段系统空闲时的每一根细的蓝线，间隔100毫秒左右，把其中一根蓝线放大来看如下图所示：



可以看到这里面基本都是gettimeofday系统调用，这一个周期大概有70次左右的gettimeofday系统调用，总共耗时约1.80毫秒。
进一步分析可以看到其中每一次gettimeofday系统调用，从进入到退出平均大约0.008毫秒，两次之间的间隔约0.024毫秒。
3.2 代码分析
通过查找代码，发现这些gettimeofday系统调用是在蓝牙模块的Sched调度主函数中发起的，主要是用来获取系统时间以判断其Task列表中的task是否有定时的任务时间以到，需要调度。而这个task列表大约有70个Task不到，在循环判断每个Task前都会通过gettimeofday系统调用更新当前时间。
通过阅读内核中gettimeofday的系统调用，发现在我们的系统中其基准依据是系统的jiff值，所以其精度在10ms左右，如果在1.80毫秒的过程中调用70次，每次得到的结果是不变的，（除非正好跨界），而蓝牙模块中上层调度对时间精度的要求也不高10ms就能接受，所以理论上说，如果每次都是1.80毫秒就能完成一次轮询的话，只需要调用一次gettimeofday系统调用就够了。
理论上说，如果一次gettimeofday系统调用都不发生，那么一次轮询的过程因该能减少8/24=33%的时间，也就是减少到1.2毫秒左右。

考虑到BT模块真正运行时，在传送数据的过程中，很多task上会有定时的任务需要执行，轮询会被这些任务打断，其次轮询也可能被其它进程打断，这样一次轮询的过程时间会不固定，所以在每个定时任务完成以后也应该调用gettimeofday更新系统当前时间。

4 后端数据采集
4.1 数据分析
基于上述的分析修改代码，重新采集数据，得到系统闲时每次轮询的系统调用情况如下图：



可以看到，一次轮询中，系统调用的次数大大减少了，其中gettimeofday系统调用大概在5-7次。在类似的操作过程和数据采集时间段过程中，一共发生 13641次gettimeofday系统调用，耗时278毫秒。调度次数减少了约90%。
而一次轮询的平均耗时平均约0.8毫秒，小于我们1.2毫秒的预估，出现这种情况，因该是由于Trace的存在，在前例中更多的系统调用导致trace模块要记录更多的数据，而也消耗了更多的CPU时间，这0.4毫秒的差异应该归于trace模块所节省的时间。所以修改代码之前假设不存在trace的干扰，估计1.1-1.2毫秒能够完成一次轮询，修改代码之后0.7-0.8毫秒，这样的改善比例就基本符合我们的预估：系统空闲时，35%的时间节约。

考虑系统闲时100毫秒才轮询一次每次轮询节约的0.5-0.6毫秒的时间，实际上相当于节约了0.5%的CPU占用率。在进行数据传输，系统忙时，轮询的频率会提高到5到30毫秒一次，这样实际节约的CPU占用率就可能在2-10%之间。

5 A2DP修改前后性能比较
5.1 数据采集方案
因为在加载LTT Trace模块的时候，总是对实际性能有所影响，所以在实测比较代码修改前后，A2DP的性能变化的数据时，使用的是没有打开LTT配置的内核。
实际测试时，用A2DP分别播放44.1k和48k的立体声音乐，音乐以Wav文件的形式存储在T-Flash卡上，以减小读文件所消耗的CPU时间。对同一首音乐分别播放两次以上，以比较音乐数据不在内存Cache中和已经在内存Cache中的性能。
使用Top查看系统的CPU占用情况，采集CPU占用情况的范围。

5.2 数据分析
A2DP使用修改前的代码：

44.1k no cache 31-33%
44.1k cache 28-33%
48k no cache 33-36%
48k cache 29-31%

A2DP使用修改后的代码：

44.1k no cache 28-30%
44.1k cache 25-28%
48k no cache 28-32%
48k cache 25-27%

可以看到：绝对CPU占用时间减少了3-5%，按相对比例来说CPU占用率减少了10-15%。符合之前的预测。