工欲善其事必先利其器，再次补充下GPU和Cuda之间的逻辑对应关系：
每个SM中有大量的寄存器资源，可以养活成千上万的线程。SM中另外一个重要资源是Shared Memory,没错，它正是软件抽象中Shared Memory的对应物。到这里，SM在软件抽象里的对应也呼之欲出了，没错，正是Block。我们不妨先摆出这个对应：
Block <-> SM
Thread执行 <-> CUDA Cores
Thread数据 <-> Register/Local Memory
同一Grid下的不同Block会被分发到不同的SM上执行。SM上可能同时存在多个Block被执行，它们不一定来自同一个kernel函数。每个Thread中的局域变量被映射到SM的寄存器上，而Thread的执行则由CUDA cores来完成。
SM上可以同时存在多少个Block？这由硬件资源的消耗决定：每个SM会占用一定数量的寄存器和Shared Memory，因此SM上同时存活的Block数目不应当超过这些硬件资源的限制。由于SM上可以同时有来自不同kernel的Block存在，因此有时候即便SM上剩余资源不足以再容纳一个kernel A的Block，但却仍可能容纳下一个kernel B的Block.
我们可以看到，SM上的CUDA核心是有限的，它们代表了能够在物理上真正并行的线程数——软件抽象里，Block中所有的线程是并行执行的，这只是个逻辑上无懈可击的抽象，事实上我们不可能对一个任意大小的Block都给出一个同等大小的CUDA核心阵列，来真正并行的执行它们。
因而有了Warp这个概念：物理上，Block被划分成一块块分别映射到CUDA核心阵列上执行，每一块就叫做一个Warp.目前，CUDA中的Warp都是从threadIdx = 0开始，以threadIdx连续的32个线程为一组划分得到，即便最后剩下的线程不足32个，也将其作为一个Warp.CUDA kernel的配置中，我们经常把Block的size设置为32的整数倍，正是为了让它能够精确划分为整数个Warp（更深刻的原因和存储器访问性能有关，但这种情况下仍然和Warp的size脱不了干系）。
现在可以整理一下这个世界的图景了。SM上存活着几个Block，每个Block中的变量占据着自己的寄存器和Shared Memory，Block被划分成32个线程组成的Warp. 这样，大量的Warp生存在SM上（但只有一个warp执行，其他的挂起/等待），等待被调度到CUDA核心阵列去执行。
Warp Scheduler正如其名，是这个Warp世界里的调度者。当一个Warp执行中出现等待（存储器读写延迟等）后，Warp Scheduler就迅速切换到下一个可执行的Warp，对其发送指令直到这个Warp又一次出现等待，周而复始。
抽象化模型：
上图关于SM和Block的关系解释一下：每个SM在逻辑上可以包含一个Block或多个Block，但每个Block一定属于唯一一个SM.
