这个问题是由于在内核中观察到的理论占有率和实际占有率之间的差异而引起的。我知道different occupancy between calculator and nvprof以及A question about the details about the distribution from blocks to SMs in CUDA。
让我们考虑一个具有6.1和15个SM的计算能力的GPU（GTX TITAN，Pascal Architecture，芯片组GP104）。并考虑2304个元素的小问题大小。
如果我们将内核配置为具有512个线程，那么每个线程将处理一个元素，我们需要5个块来操纵所有数据。而且内核是如此之小，以至于对寄存器或共享内存的资源使用没有任何限制。
理论上的占用率为1，因为可以在一个SM（2048个线程）中分配四个并发块，从而导致2048/32 = 64个活动扭曲（最大值）。
但是，已达到的占用率（由nvidia分析器报告）约为0.215，这可能与将块映射到SM中的方式有关。那么，当块的数量小于可用的SM时，如何将块调度到CUDA中的SM中？
选项1 .-将4个512线程的块调度到一个SM中，将1个512线程的块调度在另一个SM中。在这种情况下，入住人数将是（1 + 0.125）/ 2 = 0.56。我以为最后一个块只有512个线程中的256个处于活动状态才能到达数组的最后256个元素，并且它在第二个SM中分配。因此，考虑到扭曲的粒度，只有8个扭曲处于活动状态。
选项2 .-将512的每个块调度到不同的SM。由于我们有15个SM，为什么只将一个SM充满多个块？在这种情况下，每个SM共有512/32 = 16个活动扭曲（最后一个除外，后者只有256个活动线程）。因此，我们在四个SM中实现了0.25的占用率，而在最后一个SM中实现了0.125的占用率，从而得出（0.25 + 0.25 + 0.25 + 0.25 + 0.125）/ 5 = 0.225。
选项2更接近视觉分析器报告的占用率，我们认为这是幕后发生的事情。无论如何，值得一问的是：当块的数量小于可用SM时，如何将块调度到CUDA中的SM中？是否已记录？
-请注意，这不是家庭作业。在使用不同第三方库的项目中，这是一个真实的场景，这些第三方库在由多个内核组成的管道的某些步骤中要处理的元素数量很少。
正如多年来对此问题发表的评论所指出的那样，块调度程序的行为是不确定的，并且不能保证从硬件生成到硬件生成，驱动程序/运行时版本到驱动程序/运行时版本都相同，甚至平台到平台。
当然，可以使用汇编程序指令来检测代码，以提取时钟和SM ID并运行某些情况以查看设备上会发生什么。正如格雷格·史密斯（Greg Smith）在评论中指出的那样，您可能会得出这样的结论，即调度程序首先工作在广度上，将SM填充到最大可用占用量，但不一定总是那样。最终，您尝试利用发现进行尝试的任何启发式方法都将依赖于不确定的行为。
[通过评论组装而成，并作为社区Wiki条目添加，以使问题从CUDA标签的未答复队列中消失]