3. 性能追踪数据源与采集机制

在 VxWorks 上调优，第一步不是改参数，而是选对“看什么”。同一段抖动，可能来自任务调度、中断延迟、内存分配或缓存未命中，而不同的数据源看到的侧面完全不同。选错数据源，往往得到的是“看起来有数据、实际上无法定位”的结论。本节把六类常用数据源按“观测对象—采集机制—时间精度—开销—典型场景”梳理清楚，并给出选择依据。

一、六类数据源的本质差异

WindView 是 VxWorks 传统的事件追踪工具，其核心是内核插桩（instrumentation）产生的事件流：任务切换、信号量获取/释放、中断进入退出、消息队列操作等都会被打上时间戳写入事件缓冲区。它回答的是“谁在什么时候抢占了谁”，因此最适合分析任务级时序、优先级反转、调度抖动。WindView 的时间分辨率取决于系统时钟与插桩点，通常在微秒量级，但事件量大时缓冲区会溢出，需要合理设置过滤条件。

System Viewer 是较新的系统级可视化工具，通常与 VxWorks 的 system viewer instrumentation 配合，把事件流以时间轴、CPU 占用、任务状态条等形式呈现。相比 WindView，它更强调“系统整体视图”和交互式缩放，适合观察多核负载分布、长时间运行下的周期性行为。它依赖的底层数据仍是事件日志，因此采集机制与 WindView 同源，差别主要在呈现与分析能力。

Event Log 是更轻量的环形日志机制，通常由 logMsg() 或 eventLog 类接口写入，记录的是离散的、带时间戳的文本或数值事件。它的优势是开销极低、可长期驻留，适合记录“关键状态跳变”，例如看门狗喂狗、模式切换、错误码上报。缺点是粒度粗、无法还原完整调度序列，适合做“事后取证”而非“精细时序分析”。

Instrumentation（插桩） 不是单一工具，而是一类机制：在代码关键路径插入计数、时间戳或钩子函数。它可以细到函数级、循环级，甚至单条指令附近。插桩的灵活性最高，但开销也最不可控——在中断服务程序或高频循环中插桩，可能直接改变系统行为（观察者效应）。因此插桩适合“已知可疑区域、需要量化确认”的场景，而不适合全局盲扫。

硬件计数器 由 CPU 的性能监控单元（PMU）提供，例如指令数、周期数、缓存未命中、分支预测失败等。它不依赖软件插桩，开销极低，时间精度高，适合回答“CPU 到底在等什么”：是计算密集、访存瓶颈还是分支抖动。局限是它只能给出统计量，无法直接告诉你“是哪个任务导致的”，通常需要与事件日志或插桩配合做归因。

内存日志 指把追踪数据写入预留的内存缓冲区（如环形 buffer、共享内存段），而不是文件系统或串口。它的价值在于“高速、不掉速”：在实时性敏感阶段，写 Flash 或串口会引入毫秒级阻塞，而内存日志可以做到微秒级写入。代价是容量有限、掉电丢失，通常需要配合触发条件（如错误发生前后 N 毫秒）做“快照式”采集。

二、按问题选数据源：三条判断线

实际工程中，可以用三条判断线快速收敛：第一，问题是“时序”还是“统计”。如果关心“谁抢占了谁、延迟多少微秒”，必须用事件流类数据源（WindView / System Viewer / Event Log）；如果只关心“CPU 周期花在缓存还是计算”，硬件计数器更直接。第二，开销预算是否允许。中断上下文或 10μs 级周期任务中，插桩和串口输出都可能改变行为，此时应优先硬件计数器或内存日志。第三，是否需要长期驻留。Event Log 和内存日志适合长时间运行，WindView 类事件流通常只适合短时间窗口。

三、一个可复用的采集配置示例

下面给出一个“先粗后细”的采集配置思路，参数为教学示例，实际需按目标板时钟与内存调整。假设目标板主频 1GHz，预留 4MB 内存作为追踪缓冲区，系统时钟 1000Hz（tick 1ms）。

/* 示例：内存日志 + 事件过滤的采集配置（教学用，非实测） */
#define TRACE_BUF_SIZE   (4 * 1024 * 1024)   /* 4MB 环形缓冲 */
#define TRACE_WINDOW_MS  200                 /* 触发前后各 200ms */

/* 1) 分配内存日志缓冲区，避免运行时动态分配 */
char *traceBuf = (char *)memalign(64, TRACE_BUF_SIZE);

/* 2) 配置事件过滤：只保留任务切换、信号量、中断进出 */
/*    过滤可显著降低事件量，避免缓冲区过快溢出 */
eventFilterSet(EV_TASK_SWITCH | EV_SEM_TAKE | EV_SEM_GIVE
               | EV_ISR_ENTER | EV_ISR_EXIT);

/* 3) 启动采集，写入内存而非文件 */
eventLogStart(traceBuf, TRACE_BUF_SIZE, LOG_MODE_RING);

/* 4) 触发条件：错误码非零时冻结缓冲区，保留现场 */
if (g_errorCode != 0) {
    eventLogFreeze();          /* 停止写入，保留已有数据 */
    eventLogDump(traceBuf);    /* 离线解析为时间轴 */
}

这段配置的关键点有三个：过滤（只留必要事件，否则 4MB 在毫秒级就可能写满）、内存写入（避免文件系统阻塞）、触发冻结（错误发生后保留现场，而不是让环形缓冲继续覆盖）。采集完成后，把内存日志导出到主机，用 WindView 或 System Viewer 打开，即可看到任务切换与中断的时间轴。

四、结果如何判读

拿到时间轴后，重点看三类信号：任务切换间隔是否与设计周期一致，若出现周期性拉长，通常是中断或高优先级任务抢占；信号量等待段是否出现长条，若某低优先级任务持锁时间过长，就是优先级反转的典型形态；中断进出对的间距，若某 ISR 执行时间远超预期，应结合硬件计数器看是否发生缓存未命中或分支预测失败。硬件计数器给出的“每千指令缓存未命中数”若显著偏高，说明数据局部性差，可考虑调整数据结构布局或使用 DMA 减少 CPU 访存。

五、组合使用才是常态

单一数据源往往只能给出一个侧面。典型组合是：硬件计数器先定位 CPU 瓶颈类型（访存/分支/计算），WindView 或 System Viewer 还原任务级时序，Event Log 记录关键状态跳变，内存日志负责高速快照。四者配合，才能从“现象”走到“根因”。例如，计数器显示缓存未命中率高，时间轴显示某任务频繁被抢占，Event Log 记录到该任务在等一个信号量——三条线索交叉，才能确认是锁竞争导致缓存反复失效，而不是单纯的数据结构问题。

最后提醒一点：数据源的选择不是一次性的。调优初期用低开销、大范围的组合（硬件计数器 + Event Log）做筛查；锁定可疑区域后，再切换到高精度、短窗口的组合（WindView + 内存日志）做精细分析。采集配置、过滤条件、触发阈值都应随分析阶段调整，而不是一套配置跑到底。