小编rm9*_*m95的帖子

根据此链接https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html：

Warp 因等待 MIO（内存输入/输出）指令队列未满而停止。在 MIO 管道（包括特殊数学指令、动态分支以及共享内存指令）的极端利用率的情况下，这种停顿原因很严重。

根据此https://docs.nvidia.com/drive/drive_os_5.1.12.0L/nsight-graphics/activities/index.html：

可能由本地、全局、共享、属性、IPA、索引常量负载 (LDC) 和解耦数学触发。

我的理解是所有内存操作都是在LSU上执行的，所以我会想象它们一起存储在同一个指令队列中，然后由LSU单元执行。由于它们都一起排队，因此第二种解释（包括全局内存访问）对我来说更有意义。问题是，如果是这样的话，LG Throttle 就没有必要了。

MIO Throttle 实际上意味着什么？所有内存指令都存储在同一个队列中吗？

两个问题：

1. 根据 Nsight Compute 的说法，我的内核是受计算限制的。相对于峰值性能的 SM 利用率为 74%，内存利用率为 47%。然而，当我查看每个管道利用率时，LSU 利用率远高于其他管道（75% 与 10-15%）。这难道不表明我的内核受内存限制吗？如果计算和内存资源的利用率与管道利用率不对应，我不知道如何解释这些术语。

2. 调度程序每 4 个周期才发出一次，这是否意味着我的内核受到延迟限制？人们通常根据计算和内存资源的利用率来定义它。两者之间是什么关系？

这些是我的假设：

1. 有两种类型的加载：缓存和非缓存。在第一个中，流量经过 L1 和 L2，而在第二个中，流量仅经过 L2。
2. Compute Capability 6.x 和 7.x 中的默认行为是缓存访问。
3. L1 缓存行为 128 字节，L2 缓存行为 32 字节，因此对于生成的每个 L1 事务，应该有四个 L2 事务（每个扇区一个）。
4. 在Nsight中，SM->TEX请求意味着由32个线程合并而成的warp级指令。L2->TEX Returns 和 TEX->SM Returns 是每个内存单元之间传输的扇区数量的度量。

假设计算能力为 7.5，我的问题如下：

1. 第三个假设似乎暗示对于全局缓存加载，L2->TEX 返回应该始终是四的倍数，但情况并非总是如此。这里发生了什么？
2. 用 const 和 __restrict__ 限定符标记指针还有意义吗？这曾经是向编译器暗示数据是只读的，因此可以缓存在 L1/纹理缓存中，但现在所有数据都缓存在那里，无论是只读的还是非只读的。
3. 根据我的第四个假设，我认为只要 TEX->SM Returns 大于 L2->TEX Returns，差异就来自缓存命中。这是因为当缓存命中时，您会从 L1 读取一些扇区，但不会从 L2 读取任何扇区。这是真的？