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

HitTwice發表於2018-06-11

  讓各位久等了,阿里小二這就開始上新菜:“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作為例子):

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

  (圖片來源: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內部部分設計與執行機制的人來說,光看看這個列表就會莫名的興奮。

淺談GPU虛擬化技術(四)- 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的模擬可以在虛擬機器內部支援多屏顯示,其顯示效果達到了完全與物理機狀態下難分難解的地步。

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

  其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官網)

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

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

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

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

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

  GVT-g技術的渲染能力

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

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

  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左右)

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

  https://www.youtube.com/watch?v=y2SkU5JODIY

  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是一夥。

  至此,“淺談GPU虛擬化技術“系列文章完結。謝謝大家拜讀。盡情等待未來“深入GPU虛擬化技術“系列….哈


  作者:鄭曉,龍欣,彈性計算異構計算專案組

  本系列上篇文章:http://cloud.it168.com/a2018/0520/3204/000003204070.shtml

  欲瞭解更多內容,請關注鄭曉老師個人部落格

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31473948/viewspace-2155960/,如需轉載,請註明出處,否則將追究法律責任。

相關文章