關(guān)注了就能看到更多這么棒的文章哦～

Synchronized GPU priority scheduling

By Jonathan Corbet
October 22, 2021
DeepL assisted translation
https://lwn.net/Articles/873334/

在 Unix 之類的系統(tǒng)很早期的時(shí)候，就已經(jīng)實(shí)現(xiàn)了進(jìn)程優(yōu)先級(jí)的概念，優(yōu)先級(jí)高的進(jìn)程可以得到更多的 CPU 時(shí)間來(lái)完成它們的工作。如今這里的實(shí)現(xiàn)方式已經(jīng)發(fā)生了很大變化，開始有了一些替代方案（比如 deadline scheduling）可用在一些特殊場(chǎng)景，但其核心的優(yōu)先級(jí)概念（或者反序的 niceness）本質(zhì)上是沒(méi)有變化的。然而，如今的世界里越來(lái)越多的計(jì)算工作是在 CPU 之外完成的，那我們應(yīng)該如何改進(jìn)這一點(diǎn)呢？Tvrtko Ursulin 已經(jīng)準(zhǔn)備了一組 patch set，展示了如何將 nice 機(jī)制也擴(kuò)展到 GPU 這邊來(lái)用起來(lái)。

正如 Ursulin 所描述的情況，"目前的處理方式似乎越來(lái)越多地由 pipeline 來(lái)構(gòu)成，計(jì)算工作是在多個(gè)硬件設(shè)備上來(lái)完成的"。內(nèi)核直接控制了那些需要依靠 CPU 計(jì)算來(lái)完成的工作的 CPU 時(shí)間的分配。但是，越來(lái)越多的計(jì)算工作被轉(zhuǎn)移（offload）到 GPU、AI 加速器或者用于加密貨幣挖掘的外設(shè)上。這些處理器雖然能力很強(qiáng)，但也可能會(huì)因?yàn)榻o它們的工作過(guò)多而超出了自己的能力。如果它們運(yùn)行 workload 的方式與內(nèi)核對(duì)進(jìn)程優(yōu)先級(jí)的想法不一致，那么就會(huì)出現(xiàn)用戶意料之外的結(jié)果。

Ursulin 舉了一個(gè)例子，Chrome 瀏覽器會(huì)把目前不在前臺(tái)（foreground）的 tab 的優(yōu)先級(jí)。但是，如果其中一個(gè) background tab 在 GPU 中做了大量的渲染（render）工作，它可能會(huì)拖慢當(dāng)前 foreground tab 的響應(yīng)速度，盡管 background 工作應(yīng)該還是要以低優(yōu)先級(jí)來(lái)運(yùn)行。事實(shí)證明，至少其中一些 GPU （比如某些英特爾 i915 版本），可以在內(nèi)部根據(jù)優(yōu)先級(jí)進(jìn)行調(diào)度。但這需要提前告知 GPU 相關(guān)的優(yōu)先級(jí)，而目前還沒(méi)有辦法將這些在用戶空間做出的決定傳達(dá)給 GPU。

Ursulin 的方案是在 i915 驅(qū)動(dòng)中添加 "context nice" 的概念。這個(gè)值與提交這個(gè) job 的進(jìn)程的優(yōu)先級(jí)相關(guān)聯(lián)，會(huì)在有相應(yīng)能力的 GPU 中使用，來(lái)影響該工作的調(diào)度情況。這種方法是有效果的，但如果 CPU 上的進(jìn)程的優(yōu)先級(jí)發(fā)生變化了就不再準(zhǔn)確了。如果瀏覽器切換到了一個(gè)新的 tab 并想提高其優(yōu)先級(jí)，那么繼續(xù)在 GPU 側(cè)以較低的優(yōu)先級(jí)來(lái)運(yùn)行相關(guān)的工作，肯定會(huì)讓用戶不滿意的。為了避免這個(gè)問(wèn)題，Ursulin 的 patch set 為調(diào)度器添加了一個(gè)新的 notifier 機(jī)制。這樣一來(lái)，每當(dāng)一個(gè)進(jìn)程的優(yōu)先級(jí)發(fā)生變化時(shí)，相關(guān)的內(nèi)核子系統(tǒng)就可以得到通知。然后，i915 驅(qū)動(dòng)會(huì)跟這個(gè) notifier 關(guān)聯(lián)起來(lái)，從而可以修改相應(yīng)的優(yōu)先級(jí)信息，這樣就能確保 GPU 上運(yùn)行 job 的那些進(jìn)程的 CPU 優(yōu)先級(jí)總是有效的。

notifier 目前看來(lái)是這組 patch set 中最有爭(zhēng)議的部分。Ursulin 指出，每當(dāng)一個(gè)進(jìn)程的優(yōu)先級(jí)發(fā)生變化時(shí)，從 scheduler 的代碼深處來(lái)調(diào)用設(shè)備驅(qū)動(dòng)程序，可能會(huì)引入 security 問(wèn)題。John Wangghui 建議可以增加一個(gè)單獨(dú)的 "I/O nice" 值來(lái)控制 GPU 上的優(yōu)先級(jí)，這個(gè)值跟現(xiàn)存的用于 block I/O 的 "ionice" 并不相同，但其功能類似。相反，Barry Song 抱怨說(shuō)，使用簡(jiǎn)單的 nice 值是不夠的，因?yàn)樗鼪](méi)有考慮 cgroup 或者之前累計(jì)運(yùn)行的時(shí)間對(duì)占有 CPU 時(shí)間比例的影響。這可能導(dǎo)致 GPU 上的調(diào)度結(jié)果與 CPU 上的情況不一致。

Ursulin 基本上同意 Song 的批評(píng)，但也聲稱，即使只是使用進(jìn)程的 nice 值，也比在 GPU 上完全不控制執(zhí)行優(yōu)先權(quán)要好。這個(gè)初版的實(shí)現(xiàn)可以在今后有必要的時(shí)候進(jìn)行擴(kuò)展來(lái)添加 cgroup 等支持。同時(shí)，他得出結(jié)論，也許 scheduler notifier 根本就是沒(méi)有必要的。直接使用提交 job 給 GPU 時(shí)當(dāng)前的進(jìn)程的優(yōu)先級(jí)也能得到類似的效果，主要的區(qū)別是，優(yōu)先級(jí)的改變將不會(huì)影響那些已經(jīng)交給 GPU 的 job。這個(gè) patch set 的下一個(gè)版本中估計(jì)會(huì)放棄 notifier。

Ursulin 做了一些簡(jiǎn)單的基準(zhǔn)測(cè)試，其中一個(gè)圖形應(yīng)用程序與一個(gè) "GPU hog" 進(jìn)程一起運(yùn)行。如果給 GPU hog 一個(gè)低優(yōu)先級(jí)，那么圖形應(yīng)用程序比起沒(méi)有優(yōu)先級(jí)控制時(shí)能生成更高的幀率。他總結(jié)說(shuō)："所以看起來(lái)這個(gè)功能確實(shí)可以改善用戶體驗(yàn)"。因此，這項(xiàng)工作的未來(lái)版本應(yīng)該最終會(huì)進(jìn)入 mainline 的。不確定的是，在進(jìn)入 mainline 之前，它需要完成哪些改動(dòng)。

全文完