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

admin管理员组

文章数量:1574098

  用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%。符合之前的预测。        

本文标签： 模块LTT调优Bluetooth