GPU Warp Stall的原因汇总

Whistleྂ

已于 2024-08-10 18:20:54 修改

阅读量598

点赞数 16

文章标签：深度学习 nsight cuda

于 2024-08-10 17:23:18 首次发布

本文链接：https://blog.csdn.net/qq_45577173/article/details/140911913

版权

stalled_barrier：

原因：Warp 在 CTA barrier处等待同级 Warp 时停滞。大量 Warp 在barrier处等待通常是由于barrier前的代码路径发散所致。这会导致一些 Warp 等待很长时间，直到其他 Warp 到达同步点。
解决：尽可能尝试将工作划分为均匀工作负载块。如果块大小为 512 个线程或更大，请考虑将其划分为更小的组。这可以增加符合条件的 Warp 而不会影响占用率，除非共享内存成为新的占用率限制因素。此外，尝试确定哪个屏障指令导致最多停滞，并首先优化在该同步点之前执行的代码。

branch_resolving

原因：线程束（Warp）因等待分支目标计算完成以及更新线程束程序计数器而被阻塞。
解决：为了减少阻塞的周期数，可以考虑减少跳转/分支操作，并降低控制流分歧，例如通过减少代码中的条件判断或者合并条件判断。也可以参考相关的无指令状态。

dispatch_stall

线程束（Warp）因调度阻塞而被停滞。在调度期间被停滞的线程束已经有指令准备好发出，但是由于其他冲突或事件，调度器阻止了该线程束的发出。

stalled_drain

线程束（Warp）在退出后被停滞，等待所有未完成的内存操作完成以便释放该线程束的资源。大量的因释放线程束而产生的停滞通常发生在kernel末尾有大量的数据被写入内存的情况下。请确保这些存储操作的内存访问模式针对目标架构进行了优化，并且如果适用的话，考虑使用并行化的数据缩减技术。

stalled_imc_miss

线程束（Warp）因即时常量缓存（IMC）缺失而被停滞。从常量内存读取数据仅在缓存缺失时才会导致一次从设备内存中的读取；否则，它只需要一次从常量缓存中的读取。即时常量被编码到SASS指令中作为c[bank][offset]的形式。线程束内各线程访问的不同地址会被串行化，因此成本随着线程束内所有线程读取的唯一地址数量线性增加。因此，当同一个线程束内的线程只访问少数几个不同的位置时，常量缓存的效果最好。如果一个线程束内的所有线程都访问相同的位置，那么常量内存的访问速度可以像寄存器访问一样快。

lg_throttle

线程束（Warp）因等待L1指令队列用于局部和全局（LG）内存操作而而被停滞。通常，这种停滞只会在极其频繁地执行局部或全局内存指令时发生。应尽量避免冗余的全局内存访问。尝试避免使用线程局部内存，检查是否在局部作用域内声明了动态索引数组，或是kernel是否存在过大的寄存器压力导致溢出。如果适用，考虑将多个较窄的内存操作合并成较少的较宽的内存操作，并尝试交错内存操作和数学指令。

long_scoreboard

线程束（Warp）因等待L1TEX（局部、全局、表面、纹理）操作中的记分牌依赖而被停滞。找到产生等待数据的指令以确定问题所在。为了减少等待L1TEX数据访问的周期数，请验证内存访问模式是否针对目标架构进行了优化，尝试通过增加数据局部性（合并访问）来提高缓存命中率，或者改变缓存配置。考虑将经常使用的数据移动到共享内存中。

math_pipe_throttle

线程束（Warp）因等待执行pipe可用而被停滞。这种停滞发生在所有活动的线程束都在特定的、过度使用的math pipe上执行它们的下一条指令时。尝试增加活动线程束的数量以隐藏现有的延迟，或者尝试改变指令组合以更均衡地利用所有可用的pipe。

stalled_membar

线程束（Warp）因等待内存屏障而被停滞。尽量避免执行任何不必要的内存屏障，并确保所有待完成的内存操作都被充分优化以适应目标架构。

stalled_mio_throttle

线程束（Warp）因等待MIO（内存输入/输出）指令队列而被停滞。当MIO pipe被极度使用时，这种停滞原因会出现较高频率，这包括特殊数学指令、动态分支以及共享内存指令。如果是由于共享内存访问造成的，尝试使用更少但宽度更大的加载可以减轻pipe的压力。

stalled_misc

Warp was stalled for a miscellaneous hardware reason.

stalled_no_instructions

线程束（Warp）因等待被选中以获取指令或等待指令缓存缺失而被停滞。大量线程束没有获取到指令的情况通常出现在非常短的kernel中，这些kernel在网格中的工作量不足一个完整的波前。过度地在大块的汇编代码之间跳转也会导致更多线程束因为这个原因而被停滞，如果这样做会导致指令缓存缺失的话。也可以参考相关的分支解析状态。

stalled_not_selected

线程束（Warp）因等待微调度器选择该线程束以发出指令而被停滞。未被选中的线程束是指那些符合条件但本周期未被调度器选中的线程束，因为另一个线程束被选择了。大量未被选中的线程束通常意味着你有足够的线程束来掩盖线程束的延迟，你可以考虑减少活动线程束的数量，以可能提高缓存一致性及数据局部性。

stalled_selected

Warp was selected by the micro scheduler and issued an instruction.

stalled_short_scoreboard

线程束（Warp）因等待MIO（内存输入/输出）操作（非L1TEX）上的记分牌依赖而被停滞。大量因短记分牌导致的停滞的主要原因通常是共享内存的操作。其他原因包括频繁执行特殊数学指令（例如MUFU）或动态分支（例如BRX、JMX）。请参阅内存工作负载分析部分以确认是否有共享内存操作，并减少bank冲突。将频繁访问的值分配给变量可以帮助编译器使用低延迟寄存器而不是直接内存访问

stalled_sleeping

线程束（Warp）因线程束内的所有线程处于阻塞、放弃或睡眠状态而被停滞。减少执行的NANOSLEEP指令的数量，降低指定的时间延迟，并尝试将线程按组划分，使得线程束内的多个线程同时进入睡眠状态。

stalled_tex_throttle

线程束（Warp）因等待L1指令队列用于纹理操作而被停滞。当L1TEX pipe被极度使用时，这种停滞原因会出现较高频率。尝试减少纹理获取、表面加载、表面存储或解耦的数学操作。如果适用，考虑将多个较窄的内存操作合并成较少的较宽的内存操作，并尝试交错内存操作和数学指令。考虑将纹理查找或表面加载转换为全局内存查找。纹理每周期可以接受四个线程的请求，而全局内存可以接受32个线程的请求。