以前读完论文并没有写keynotes的习惯,顶多在mendeley上做些标注,但是过段时间再看,还是需要花费一定的时间来理顺思路。所以准备从现在开始对阅读过的论文做一些自己认为重要的备注。

GPU Scheduling on the NVIDIA TX2: Hidden Details Revealed

2017 IEEE Real-Time Systems Symposium (RTSS) (2017)

Paris, France

Dec 5, 2017 to Dec 8, 2017

ISSN: 2576-3172

ISBN: 978-1-5386-1415-0

主要是对NVIDIA GPU未公开的调度机制在Jetson TX2上做了测试验证。涉及到的Queue都是FIFO模式。

TX2有两个execution engine (EE),一个copy engine (CE) 。一个EE可以同时执行多个kernels,一个CE一次只能执行一个copy操作,EE和CE可以并发。

同一个stream里的操作是串行的,不同stream里操作的执行取决于GPU调度策略。默认所有操作都在NULL Stream,而且他的优先级也比较奇葩。

复制操作必须等到同一个stream里之前的kernel发射以后,才能开始。

GPU调度策略

多个stream里的操作将被按照发射顺序放进EE的队列里进行任务的分派assign。也就是说,只有在队首的Kernel才会被挑选进入EE queue。

论文里的图都是一个EE queue做的模型,在从多个Stream Queue中挑选任务的规则应该是按照发射时间先后。

后面好像没有对两个EE queue进行分析,所以在多个EE queue情况下,Kernel的分派策略没有说明,不知道是否还是按照Kernel的发射顺序。

对于EE queue中的任务是否要被分派至SM上,则是大家熟知的规则:寄存器、线程、Shared memory。

不同架构的硬件限制在相应的白皮书或者cuda samples路径的common tools文件夹中有计算occupancy的excel表格,第三个sheet就是每一种架构的硬件限制信息。

maxregcount可以用来限制寄存器数量。

其实这个参数的使用环境限制挺大的,在寄存器限制还是64的上古架构非常有用,但是目前的寄存器限制一般是255 per thread。

我感觉ptxas目前的寄存器分配策略非常低效,因为看起来它在尽可能减少寄存器的使用数量,而不是提供多个不同寄存器需求级别的分配策略。导致即便硬件提供了255的限制,编译出来的寄存器数量还是远远小于255。一般情况下,寄存器分配策略中,更多的寄存器,意味着更少的指令,更快的速度。

NULL Stream是个特殊的stream,前面的讨论都是user specified stream。

论文中Figure5的我有的疑问是,K2:0为什么不调度到SM1的1.0-2.0时间上去?看起来作者认为NULL Stream里的kernel必须等待其他stream里的kernel完成?但是在其总结的规律里,只跟launch time有关而不是end time。

Stream 也有优先级的设置。后面的我目前不是特别关心,没有仔细阅读。不过总体来看就是一个正常的优先级调度策略,当然包括设置的优先级和资源优先级两个参数。

总的来说这篇文章不错,在实验中验证了部分Nvidia的调度策略,明确了大家推测已久的一些规则。


文章版权归 FindHao 所有丨本站默认采用CC-BY-NC-SA 4.0协议进行授权|
转载必须包含本声明,并以超链接形式注明作者 FindHao 和本文原始地址:
https://findhao.net/easycoding/2464.html

Comments