apache Python 开源 google 微软 mysql wordpress 编程 云计算 Android linux Ubuntu 程序员 shell java nginx Firefox php centos Windows

淺談GPU虛擬化技術(四)- GPU分片虛擬化

對於“分片”的理解,相信大家已經不陌生了。此處的分片從兩個維度上來定義:其一,是對GPU在時間片段上的劃分,與CPU的進程調度類似,一個物理GPU的計算engine在幾個vGPU之間共享,而調度時間片一般都在1ms-10ms左右,其二,是對GPU資源的劃分,主要是指對GPU顯存的劃分,以NVIDIA為例,一個物理GPU帶有16GB的顯存,那麽按照16個vGPU來劃分,每個vGPU得到1GB的顯存。由於安全隔離的要求,每個vGPU獨享分配給它的顯存,不會與其他vGPU共享。

技術上講GPU分片虛擬化,就是指基於VFIO mediated passthrough framework的GPU虛擬化方案。該方案由NVIDIA提出,並聯合Intel一起提交到了Linux kernel 4.10代碼庫,該方案的kernel部分代碼簡稱mdev模塊。隨後Redhat Enterprise,CentOS最新的發行版花了不少力氣又backporting到了3.10.x kernel。所以如果目前采用最新的Redhat 發行版(企業版或者centos7.x)等都已經自帶mdev模塊。而如果采用ubuntu17.x 以後版本的話,不但自帶mdev功能,連Intel GPU驅動(i915)也已經更新到支持vGPU。無需任何代碼編譯就可以直接體驗vGPU虛擬機功能。

那麽什麽叫mediated passthrough呢? 它與pass through的區別是什麽呢? 一句話解釋:把會影響性能的訪問直接passthrough給虛擬機,把性能無關,功能性的MMIO訪問做攔截並在mdev模塊內做模擬。太過細節的東西詳見後續篇章。

GPU分片虛擬化框架

GPU分片虛擬化的方案被NVIDIA與Intel兩家GPU廠家所采用。NVIDIA GRID vGPU系列與Intel的GVT-g(XenGT or KVMGT)。

當然光有內核的支持還不夠,需要加上qemu v2.0 以後版本,加上Intel或者NVIDIA自帶的GPU mdev驅動(也就是對GPU MMIO訪問的模擬),那麽GPU分片虛擬化的整個路徑就全了。而GPU廠家的mdev驅動是否開源取決於自己。按照一貫的作風,Intel開源了其絕大部分代碼,包括最新的基於mdev的GPU熱遷移技術,而NVIDIA也保持其一貫作風:不公開。

GPU分片虛擬化看起來整個框架就如下圖一樣(以KVMGT作為例子):

(圖片來源:https://01.org/sites/default/files/documentation/an_introduction_to_intel_GVT-g_for_external.pdf)

可以從上圖看到vGPU的模擬是通過kvmGT(Intel)或者NVIDIA-vgpu-vfio(NVIDIA)來完成。該模塊只模擬對MMIO的訪問,也就是功能性,不影響性能的GPU寄存器。而對GPU aperture和GPU graphic memory則通過VFIO的passthrough方式直接映射到VM內部。

值得註意的是一般Passthrough的方式都依賴IOMMU來完成GPA到HPA的地址轉換,而GPU的分片虛擬化完全不依賴IOMMU,也就是說其vGPU的cmd提交(內含GPA地址)並不能直接運行於GPU硬件之上,至少需要有一個GPA到HPA的翻譯過程。該過程可以通過host端的cmd掃描來修復(KVMGT),NVIDIA GRID vGPU每一個context有其內部page table,會通過修改page table來實現。

由於NVIDIA GRID vGPU代碼閉源,我們將著重介紹Intel的GVT-g方案。

Intel GVT-g的介紹

說起GVT-g我大概可以講上三天三夜。當然大夥這兒也未必想聽。撿簡潔的說起:

Kernel 與 mdev驅動源碼:

https://github.com/intel/GVT-linux

qemu:

https://github.com/intel/IGVTg-qemu

setup文檔:

https://github.com/intel/GVT-linux/wiki/GVTg_Setup_Guide

我們可以在任何一個帶集成顯卡Intel SKL/BDW的機器上運行GVT-g虛擬化的方案。GVT-g的GPU虛擬化方案也被用到了嵌入式,車載系統等領域(ARCN hypervisor)。

幹貨來了J 對於想了解GPU的運作,以及軟硬件規範的,Intel其實已經開源了其大部分標準。

https://01.org/linuxgraphics/documentation/hardware-specification-prms

截個屏,對於想了解GPU內部部分設計與運行機制的人來說,光看看這個列表就會莫名的興奮。

GVT-g由於是基於Intel的集成顯卡,所以對運行環境的硬件要求非常低。任何Intel的帶GPU的ATOM,Mobile Core或者Xeon E3等等CPU都能支持vGPU虛擬化(HSW,BDW,SKL系列CPU)。

又同時GVT-g完全免費,用戶不需要花費額外的費用來支持vGPU的應用。

也正是這些優點,使得GVT-g可以被廣泛的運用到任何對終端有虛擬化與顯示要求的場景。比如XenClient,比如ARCN等等。

GVT-g的優點之一在於對其本地顯示的良好支持。

GVT-g在內部虛擬了一個類似display pipeline的組件,來接管GPU display port上連接的顯示器。所以vGPU內部framebuffer的信息可以被GVT-g快速的顯示在物理GPU連接的顯示器上。其顯示FPS可以到達驚人的60FPS。完全達到了物理顯示器的效果。更為強悍的是,vGPU通過對這些port和EDID的模擬可以在虛擬機內部支持多屏顯示,其顯示效果達到了完全與物理機狀態下難分難解的地步。

其framebuffer的傳輸路徑可謂九曲十八彎…但效果還不錯。60fps妥妥的。

內嵌一段視頻,來描述兩個VM是如何共享同一個物理顯示器,並能做到流暢切換:

https://01.org/sites/default/files/downloads/iGVT-g/iGVT-g-demokvmgt.zip

GVT-g的Media transcoding能力

Intel GPU對media decoding/encoding的硬件支持是其一大特色。GVT-g在vGPU虛擬化的過程中也加入了對media decoding/encoding的支持。其虛擬化後的vGPU的編解碼吞吐能力可以達到驚人的99%物理GPU的吞吐量(HSW GPU 2014年)。仗著當年vGPU media transcoding 99%物理性能的優勢,GVT-g團隊在當年深圳舉行的IDF上提出了Intel GVT-g對media cloud的未來設想。並在2015的巴塞羅那世界移動大會上聯合華為做了一個GVT-g對Media Cloud的展臺。其架構設想如下圖(圖中綠色方塊為Media Cloud的發力點,截圖來自GVTg官網)

https://01.org/sites/default/files/documentation/intel_graphics_virtualization_for_media_cloud.pdf

隨後由於Intel GPU軟硬件設計人員在下一代GPU中的設計沒有全面考慮分片虛擬化場景,在一定程度上破壞了GVT-g在media transcoding上面的優勢。目前在BDW和SKL上面的vGPU編解碼效率已經不盡人意,失去了其優勢。

不得不感嘆一下,曾夢想仗劍走天涯….如今已涼涼

GVT-g技術的渲染能力

直接從Intel GVT的官網摳數據(https://01.org/sites/default/files/documentation/an_introduction_to_intel_GVT-g_for_external.pdf)


vGPU基本上對於Graphic rendering的能力是物理GPU的80%以上,一般在90%左右,回憶一下我們在第三章中介紹的AMD的SRIOV類型GPU虛擬化下vGPU的渲染能力可以達到97%左右。同時本身Intel GPU物理渲染能力與AMD/NVIDIA的同時代GPU比較也遠遠處於下風。所以對於強調大計算力的3D渲染場景的vGPU應用,Intel GPU的應用比較受限。

從技術的角度來看,GVT-g對於vGPU的性能損耗主要開銷在於對其中斷相關MMIO的模擬。比如對於AMD的SRIOV方案,其VM中對vGPU的MMIO訪問完全沒有虛擬化開銷,不會有trap發生。即便不采用SRIOV方案,一般來說,硬件設計很多時候會考慮到對虛擬化的要求,並做出有利於虛擬化框架的改動。類似這種中斷相關對性能敏感的MMIO是需要特殊設計以減少在虛擬化下的損耗。而像Intel GPU這樣完全不考慮虛擬化開銷的硬件設計,使得GVT-g在軟件層面無論如何優化都無法達到潛在對手的高度。為什麽說是潛在對手呢?因為對於NVIDIA來說,GVT-g與Intel GPU根本就算不上是一個對手。

GVT-g的GPGPU能力

GVT-g vGPU只做到了可以運行OpenCL,而對performance等並沒有做任何優化。Intel GPU硬件在computing和深度學習方面本就不是強項。

GVT-g的Live Migration

GVT-g的vGPU在軟件層次做到了極致。其早在2015年末就開始了對vGPU的熱遷移支持。並在2016年對外公布。而GRID vGPU只在最近才有消息透露其在Citrix的某些產品上支持vGPU的熱遷移,並只支持部分GPU型號。而AMD的SRIOV方案至今沒有熱遷移方面的公開消息。

vGPU的熱遷移細節太過技術化,此處不多做介紹,但是當年第一個支持vGPU的VM渲染實時遷移的效果還是讓人印象深刻的。其視頻是基於KVM的vGPU遷移過程。

從視頻截圖中可以看出,其所有遷移過程在小於1秒的時間內完成並顯示在新機器上了。(Demo的實際整體遷移時間為300ms左右)

GVT-g的調度

實話說GVT-g的調度並沒有AMD SRIOV vGPU做的好。其調度粒度雖然是在1ms時間片的維度上做調度和vGPU切換。但是由於GPU軟硬件對preempt功能的支持尚未完備,實際調度往往需要等當前vGPU的任務結束才能開始。在渲染大幀的情況下vGPU調度信息一般的統計顯示,其基本上在5-10ms左右的間隔做vGPU切換。回憶一下AMD的SRIOV是嚴格6ms一次。而NVIDIA的GRID vGPU有多種調度策略,由於閉源,沒有更多的信息可以拿到其調度信息。有心得讀者可以在虛擬機下通過rebuild NVIDIA Guest Linux驅動研究一下。

GVT-g得局限性

當然悲催的是,也正是由於GVT-g是基於Intel的集成顯卡,即便是免費附加增值服務,GVT-g在數據中心也很少被采用。第一本身的GPU性能無法與AMD/NVIDIA同類產品競爭,第二數據中心追求的是高密度運用,集成顯卡無論如何都無法做到一機多卡的情況,在機房機架,寸土寸金的地方,大家都會考慮成本。Intel也作過一些嘗試,把幾個Xeon E3的CPU做到一塊PCIE板卡上面增加其計算密度,然而其功耗和售價都無法與其他對手競爭。同時這種設計也使得軟件系統復雜難維護。

NVIDIA GRID vGPU的介紹

閉源系統,沒什麽好介紹的。值得一提的是NVIDIA GRID vGPU是正式商用的方案。其技術在VMWare,XenServer,Redhat等大廠已經久經考驗。

GRID vGPU在VDI上的運用

GRID vGPU在VDI的運用要早於GVT-g和AMD的SRIOV。早期GRID已經與VMWare合作堆出了一些列remote display的方案。GRID vGPU擅長remote display,GVT-g擅長local display,各有優點。

GRID vGPU渲染能力

對比GVT-g,GRID vGPU在圖形渲染方面的虛擬化損耗非常小幾乎與AMD SRIOV的類似,可以達到其passthrough狀態下的99%左右。而GVT-g卻在90%左右。

GRID vGPU通用計算能力

雖然沒有多少人會在一個分片GPU虛擬化的VM內部作深度學習計算,但GRID vGPU的計算性能也已經可以達到其passthrough狀態下的80%以上。其目前vGPU 1:1分片(一個物理GPU只分一個vGPU)情況下,各項性能指標幾乎已經與passthrough GPU的方案不相上下。完全可以取代GPU passthrough的方案。但對多vGPU的支持,目前GRID vGPU無法支持。這是其對比GPU passthrough方案最大的弊端。NVIDIA顯然不會坐視不理,GRID vGPU將來一定會考慮多vGPU的場景並支持P2P。GRID vGPU另外一個對比passthrough GPU的好處就是可以在Host端對vGPU關鍵性能指標的監控。還記得我們在本系列第二章介紹GPU passthrough方案的時候提到的:GPU passthrough方法的固有缺點嗎?GPU passthrough情況下host端對vGPU無法進行有效監控,而這在GRID vGPU的場景下完全不成問題。

GRID vGPU分片虛擬化的方案相對GPU passthrough來說部署比較困難,由於閉源,其並不像Intel GVT-g一樣一切開源並整合到kernel代碼庫中,一般廠商需要使用該技術還得作不同程度的kernel適配和調試。發布周期至少半年以上。

各個GPU虛擬化方案的一些實現細節異同

Mediated passthrough (mdev)

我們再次來回顧一下什麽叫mediated passthrough。首先應該查看kernel document:

https://github.com/torvalds/linux/blob/master/Documentation/vfio-mediated-device.txt

之前已經提到Mediated是指對MMIO 訪問的攔截和emulation,對DMA transfer的提交作GFN到PFN的地址轉換。

NVIDIA在2016年的KVM forum上面已經很詳細的介紹了這些細節。

http://www.linux-kvm.org/images/5/59/02x03-Neo_Jia_and_Kirti_Wankhede-vGPU_on_KVM-A_VFIO_based_Framework.pdf

GPU command的提交方式

三個GPU虛擬化的方案在GPU command(batch buffer)的提交方式上是由本質區別的。GVT-g與GRID vGPU作為分片虛擬化的代表,其任何vGPU的cmd提交都會被攔截到host端作emulation。並通過host的處理以後由host代替vGPU提交到物理GPU。AMD SRIOV方案其本質上也是一種GPU分片虛擬化,並且其與mdev的區別就是分片方式是:通過SRIOV的標準還是通過mdev軟件方式實施,而對SRIOV  vGPU的emulation則在Host端的GPU硬件,Firmware,GIM驅動共同完成。

而GPU passthrough方式下,vGPU的cmd直接由虛擬機內部提交。無需再繞道Host端。由此 passthrough下,無法對虛擬機內部vGPU的運作做出監控。

簡單點講:GVT-g與GRID vGPU的提交方式為一類,SRIOV與GPU passthrough方式為另一類。

IOMMU

分片虛擬化不需要IOMMU硬件的支持。其只需要VFIO模塊添加type1 IOMMU的驅動,來通知host將要進行的DMA傳輸的GFN,VA等信息,並在Host端的mdev設備驅動層完成GFN到PFN的翻譯處理。可以理解為軟件層面上的IOMMU操作。

而AMD SRIOV與GPU passthrough方式下,IOMMU是必備組件。尤其IOMMU硬件完成GFN到PFN的地址轉換。

簡而言之,GVT-g,GRID vGPU是一夥,SRIOV,GPU passthrough是一夥。

延伸阅读

    评论