背景介绍：Host Bound问题

在NPU训练和推理场景中，Host侧（CPU）的任务下发（如算子调度、内存分配）与Device侧（NPU）的任务执行是异步进行的。当Host侧任务下发耗时超过Device侧任务执行耗时，Device会因等待新任务而处于空闲状态，形成性能瓶颈，即Host Bound问题。

Host Bound问题现象整体表现为Free（NPU空闲）占比高（注意：Free占比高不一定是Host Bound问题），其细分现象包含但不限于：

• Host侧某算子下发耗时长
• Host侧出现大量长耗时空泡
• Host侧流水中断

Host Bound问题的根因大多数归结为：

• Host侧线程抢占；
• Host侧某算子/函数等待计算结果返回；
• Host侧长时间等待资源（如锁资源），或资源未及时释放导致阻塞；
• Host侧下发队列满；
• H2D数据传输异常。

其中，比较常见的是Host侧线程抢占问题。此类问题通常通过ftrace（Linux内核内置的一种跟踪工具）来排查，但是存在较大的困难：调优人员难以将ftrace数据和Profiling对齐，联合分析CPU与NPU的协同情况。

针对这个问题，MindStudio Insight推出了基于ftrace的采集解析脚本，解析结果可导入Insight可视化界面，联合Profiling展示，帮助用户实现ftrace数据和Profiling数据联合分析，优化Host瓶颈。

Host Bound问题分析与解决思路

利用MindStudio Insight分析Host Bound问题时，可以根据以下思路：

使用MindStudio Insight集群分析功能进行整体分析，初步确定是否存在下发慢卡；

同步采集Profiling和ftrace数据，联合分析CPU与NPU协同情况；

根据分析结果，进行针对性优化，例如绑核优化、核隔离等方式，减少进程抢占现象。

Host Bound优化实战案例

问题背景

某Linux服务器，已经发现了性能膨胀和Host侧空泡问题，但是仅仅从Profiling数据，无法判断真实原因，缺少对于Host侧的性能分析手段。

使用MindStudio Insight的集群分析功能，看到卡3的Free占比明显过高，为下发慢卡。

图1 集群分析初步确定是否存在下发慢卡

Profiling结合ftrace分析抢占情况

Profiling分析Device侧现象

通过Profiling数据，对Device侧分析（下图），可以很明显的看到卡3、卡5在黄色框选部分存在空泡，没有充分利用硬件性能。

图2 总体Device侧执行情况

以卡3为例，其Host To Device连线坡度逐渐垂直，说明卡3 Host侧下发任务较慢，Device侧出现空转，导致硬件资源浪费。

图3 卡3 Host To Device下发连线

经过以上分析，基本可以确认，Host Bound下发慢卡降低了NPU利用率。但此时，仅通过Profiling数据，已经不足够分析Host侧问题根因了。接下来需要结合ftrace数据，分析当时CPU的行为有哪些异常。

采集ftrace数据

利用MindStudio Insight提供的采集脚本trace_record.py，采集ftrace数据。运行结束后在当前目录下生成ftrace.txt文件。然后使用转换脚本trace_convert.py，将ftrace数据格式转换为能够导入MindStudio Insight的格式。

以上脚本，可以在MindStudio Insight的开源代码仓中获取：

https://gitcode.com/Ascend/msinsight/tree/master/scripts/ftrace_tools

Profiling与ftrace联合分析

发现问题一：ACLThread被CANN线程抢占

如下图4所示，可以看到async_task_queue连线（用于关联Python至CANN的任务下发关系）坡度非常大，这说明Python层的下发队列中有任务，但是一直没有下发，造成大约3.2ms的空泡。

进一步定位问题原因。该环境已经使用过绑核，绑核策略中，对应卡4的ACLThread绑在CPU 90上。因此，将泳道名称为CPU 90的ftrace泳道置顶，区域框选后发现，卡4下发慢时，对应的Host侧CPU被dev14_sq_task进程抢占。

图4 卡4有大约 3.2ms的空泡

定位结论与解决措施：

dev_sq_task责将任务传输到Device上，任务优先级较高，抢占了ACLThread。在此期间，ACLThread一直处于就绪但未被调度的状态，导致了3.2ms空泡。因此，需要将ACLThread、dev_sq_task分别绑核。

发现问题二：ACLThread被系统级线程systemctl抢占

如下图5所示，在两个标记（绿色旗帜和红色旗帜之间）区域，对应CPU被systemctl线程抢占并打断，导致Host Bound问题。图6可以看得更清楚。systemctl线程是内核线程，主要用来做Linux上各种服务的调度和更新，优先级高于用户线程。

图5 卡4分析系统线程抢占

图6 系统线程抢占 ACLThread

解决措施：

启用/etc/systemd/system.conf中的CPU亲和性配置属性，将系统线程绑定在某几个特定的CPU核心上，以避免对用户线程的抢占。

发现问题三：频繁唤醒休眠导致CPU空转

如下图7所示，发现慢卡主进程虽然没有被抢占，但是主进程频繁在sched_waking状态。

图7 frace.txt的sched_waking状态频繁

解决措施：

使用CANN包提供的下发流水优化特性，开启二级流水优化，以避免主进程过快进入休眠状态而被频繁唤醒。可通过export TASK_QUEUE_ENABLE=2环境变量使能该特性，详见：

https://www.hiascend.com/document/detail/zh/canncommercial/83RC1/acce/ascendtb/ascendtb_0032.html

优化结果

通过Profiling结合ftrace分析进程抢占和频繁调度问题，并且针对问题完成绑核、使能下发流水优化等方法，最终将Free占比从18%降低到0.38%，Host Bound问题得到极大缓解。

图8 优化前Free占比

图9 优化后Free占比

总结

Host Bound问题已经成为模型训练与推理部署中的高频问题，但是一直以来，调优人员都缺乏有效手段，能够同时观测Host侧和Device侧的执行情况。MindStudio提供了一种将Profiling数据与ftrace数据联合分析的方案，打开了Host侧黑盒，让下发问题看得准，调得快。

工具链接如下

MindStudio Insight可视化工具：

https://gitcode.com/Ascend/msinsight

ftrace数据采集与解析脚本：

https://gitcode.com/Ascend/msinsight/tree/master/scripts/ftrace_tools

Profiling采集工具：

https://gitcode.com/Ascend/msprof