揭秘ARM架构对Linux调测特性的支持-电子发烧友网

一、浅谈手机性能的可观测性

1.概述

手机上的性能指标是综合的变化，由上图可以看的出来手机更关注人跟机器的交互这，云系统则是比较关注机器跟机器的交互。

手机系统比较特别的地方在于资源都是比较受限，例如: 电量，性能…因此针对用户体验是需要特别庖丁解牛来建立指标。

指标(METRIC) -业界有特定的体验度量模型，目标是发现产品和服务中的问题及理解使用者的行为和偏好。

性能体验度量是多层次，多个维度的，只用一项指标去表征的所有性能特征是远远不够的。

以上是几个个常用指标，这些指标常常是互相搭配的例如Andrid近年常用的GSM+HEART。度量模型围绕用户使用的旅程，识别关键体验路径(KEP)，为不同接触点分解出不同的性能指标。

2.性能追踪

实际上如何构建手机可观测性，我们都会采取分层次拆解，由上图可以看的出来藉助于Android/Linux系统的生态系已经有不少工具可以用于追踪系统的信息。

性能追踪在手机装置面临的挑战:

1、低开销：不会降低用户的体验，因为手机资源是受限的所以如何有性的采集会是很大的考验。

2、不可接触：开发人员无法实时获取使用者的故障第一现场信息，用户很多操作行为都是不容易在现，因此识别关键体验路径会是开发的过程之一。

3、偶发性：低概率，不易复现(Heisen berg Bug)，对于第三方应用跟系统交互或是用户行为常常有偶发性不易在现的问题需要准确的追踪机制辅助找到原因。

4、不可预见：用已知模式分析未知问题。

讲师介绍了一些Android上常见的工具

žSystrace : 用于将设备活动保存到跟踪档的Android 工具。

žcpu_profile : 在android平台实现周期性采集调用栈。

žsimpleperf : simpleperf是Anroid平台的一套性能分析工具，功能大致与linux perf相似。

žnanotrace : 通过在虚拟机（包括解析器和编译程序）中插桩，获取从APK到framework层的执行路径的调用链和函数执行时长。

žobjtrace : 动态跟踪函数参数值。

žblktrace : blktrace 结合btt可以统计一个IO是在调度队列停留的时间长，还是在硬件上消耗的时间长。

žHitrace : 对于跨设备/进程/线程的业务流程处理，通过相同的traceid在整个业务流程中传递，将调用层次、各种输出信息关联和展现。

3.可观测性之Logging

上图由上而下的拆解展示日志的重要性，首先我们需要了解用户行为，关注用户体验并记录对应的错误日志，当时系统状态与硬件状态用于改善用户体验。

手机系统的日志系统时常需要整合第三方应用，因为第三方应用不开源，管理日志上常常没有足够权限，还有手机储存大小受限因此最终的日志系统方案都是朝可以汇整日志并更精准建立模型为目标。

总结以上几点用户体验是感性的，不单单只是数字因此讲者认科技应该是有温度的。

Q&A

Q : 是否有AI优化思路？

A: 目前还在努力，有尝试用AI分析用户体验不过效果不明显。目前比较多还是在做基础体验度量。

Q : 跑分跟用户体验怎么看？

A: 跑分不能直接当用户体验侦率，累积布局偏移可參考。

Q: nanotrace可否第三方插庄？

A: yes

Q : 是否能找到唤醒源？

A:可打开irq，ipi中断事件可以看到换醒源。

二、揭秘ARM架构对Linux调测特性的支持

讲师简介：张健, 现就职于北京大简技术有限公司, 14年ARM架构和操作系统一线研发经验. 在北京, 柏林, 拉斯维加斯, 多地发表技术演讲。

首先，本次分享从调试视角、性能影响两个角度出发，对调试特性进行了宏观的分类。

1.调试类型

调试包含两个维度的特性：调试视角维度与性能影响维度。

1.调试视角维度

从调试视角维度出发，调试分为external debug与self-hosted debug，前者包括openocd、kgdb、ftrace、perf等内核调试基础设施，后者则是通过JTAG、FTOI等体系结构相关调试接口连接芯片，同时用调试软件控制硬件调试器进行调试。

其中，红色所示技术为硬件调试接口，蓝色所示技术为相关软件调试工具。软硬件调试工具共享CPU和内核所提供的调试能力。

2.性能影响维度

从性能影响维度出发，调试分为影响（多为停止）当前CPU状态的侵入式调试和不影响CPU运行的非侵入式调试。前者多会暂停当前CPU的执行流，同时通过相关机制（比如，AR cross trigger）告知其他核当前被调试的状态，从而影响系统状态。

这种调试类型虽然带来了强大的调试能力，但是在芯片和内核的设计开发时需要考虑CPU调试过程中与其他外围设备的关系，因为CPU的调试状态不会影响到其他硬件，一致性等问题是该方法的经典挑战；对于非侵入式的调试类型，它不会直接停止当前的CPU运行状态，更多对系统起到监控跟踪的作用。

接下来，分享从断点、Trace、PMU三类调试手段出发讲述ARM架构的系统调试特性。

2.侵入式调试手段之断点

断点调试是侵入式的，单纯依赖用户态基础设施或顶层应用无法达到启停系统的能力要求。因此，断点调试的设计需要硬件和操作系统的支持，即断点调试要有陷入高特权级别环境的能力。

用户通过配置编译选项获得指定平台下的gdb调试器，将被追踪程序当作参数传递gdb调试器，gdb调试器fork出被调试程序子进程，两者通过PTRACE_XXX请求建立连接。

对于软件断点，gdb将通过符号表等信息在开发者指定的位置填入调试指令（x86为INT3，ARM为BRK/BRKT）；对于硬件断点，gdb会将指定位置的地址写入到调试寄存器中。

当程序运行至软件断点或硬件断点处，子进程会触发相应异常，待异常信号被gdb捕获后，通过比对记录的断点信息来判断是否是调试原因所触发的异常，如此来实现gdb调试进程的启停能力。

3.非侵入调试类型之Trace

ARM Coresight架构是遵循可观测性的架构设计，Cortex Processor后的ETM负责在处理器外部抓取指令序列，不影响CPU的运行状态。并且，Trace信息的传输未经系统总线，减少了对系统带宽的影响。Coresight架构中存在多个执行流抓取点，存在多个对应的ETM，多个ETM收集的信息会传入下游的Funnel，Funnel将根据数据所存在的信息将执行流信息进行分流处理。