本站小編為你精心準備了GPU虛擬化環境下的數據通信策略參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

1引言

虛擬化技術對物理資源進行邏輯抽象和統一表示，降低了資源管理的復雜度，提高了物理資源的利用率和運營效率，從而有效地降低了運營成本[1]。同時，現代gpu的計算能力比同時代CPU的計算能力勝出幾個數量級，因而商業界、學術界紛紛致力于GPU虛擬化技術的開發[2]。然而在目前的虛擬化環境下并沒有一個通用且高效率的RPC系統，傳統的如XMLRPC[3]、CORBA[4]、ICE[5]等應用則只針對開放的網絡或分布式環境，當把它們移植到虛擬化環境中則會在系統吞吐率、延遲以及CPU占用方面出現很大的劣勢，基本無法應用于實際項目。2006年，Nvidia公司統一架構CUDA[6]（ComputeUnifiedDeviceArchitecture)）的誕生，引發了GPU通用計算領域（GPGPU，GeneralPurposecomputingonGraphicsProcessingUnits）的迅猛發展，大大簡化了GPU的編程環境。當采用多GPU并行處理大規模的數據時，數據通信的選擇問題，已經成為在虛擬化環境下進行CUDA應用開發不可越過的難題。為了提高在虛擬化環境下多GPU協同計算的性能，本文首先在系統層分析由于虛擬化帶來性能影響的主要因素，通過對比同一虛擬化平臺下的不同數據通信策略得出特定虛擬化平臺的最佳通信方式。在應用層方面，通過研究多GPU卡的不同的數據傳輸機制，得到影響多GPU協同運算效率的主要因素。

2虛擬機域間通信策略

2.1基于Xen的虛擬機通信方式Xen平臺下虛擬機域間通信優化的解決方案主要有三種，分別是XenSocket[7]、XWAY[8]和XenLoop[9]。XenSocket是在Xen中基于socket的解決方案，旨在提高虛擬機域間通信的吞吐率。XenSocket的API采用標準的socketAPI接口，在socket的接口下，它使用Xen提供的共享內存來實現虛擬機之間高速的數據傳輸[10]。XWAY使得在同一物理機不同虛擬機之間運行的程序可以通過標準的socketAPI來進行通信，不僅實現了域間通信的高帶寬、低延遲，同時也充分地保證了對二進制兼容性，使任何基于socketAPI的網絡程序都可以直接享用XWAY帶來的高速域間通信的體驗[11]。XenLoop是一個Xen平臺下另一虛擬機域間通信方案，該方案是一個完全透明的、高性能的虛擬機域間的網絡環回通道。Xenloop可使同一物理機不同虛擬機之間可以直接進行數據通信而不需要第三方軟件的參與，同時可以不犧牲應用層的透明性，應用程序不用作任何修改便可以無縫地運行。XenLoop還實現了在Xen虛擬化平臺下虛擬機域間的高速通信[12]。

2.2VMwareVMware開發了一套相應的虛擬機通信接口VMCI（VirtualMachineCommunicationInterface）。VMCI[13]是一個作用在應用層的方案，提供在VMware系列虛擬機平臺下的快速、高效的域間通信通道，使得客戶端虛擬機與客戶端虛擬機、客戶端虛擬機與物理機之間能夠實現高速的通信。VMCI實現兩類接口，一類是數據報API，一類是共享內存API。VMCI屬于VMware的商業產品，內部實現細節目前并未披露[14]。由于目前并不存在適用于虛擬機中的顯卡驅動，本文通過在ESXi中某一虛擬機中使用PCIpass-through（也即VMware的設備直通）技術，使得該虛擬機獲得物理機中GPU的訪問權。

3GPU內部數據傳輸

隨著2011年CUDA4.0由NVIDIA作為一個全新版本后，其功能特性大幅度增加，主要涉及應用程序移植的簡化、多GPU編程的加速、開發工具的增加和改進三個方面。在多GPU通信方面，在CUDA4.0之前，多個GPU在同一節點內相互訪問，需要首先將GPU中的數據傳輸給CPU，再通過CPU的中轉完成GPU間的數據交互。而在CUDA4.0之后，NVDIA實現了不同GPU可以直接進行傳輸，且傳輸可以一次完成。另外通過NVIDIA的GPUDirect2.0[15]技術使一臺服務器內多個GPU之間直接點對點通信，不僅繞開了主機端的參與，同時讓多GPU編程更加輕松且傳輸效率也大大增強。

3.1統一虛擬地址空間統一虛擬地址空間（UnifiedVirtualAddressing，UVA）模型為主機與系統內所有的設備提供了單一地址空間[16]。這一模型將CUDA中包括CPU以及GPU在內的所有指令執行過程放入同一個地址空間。這之前每個GPU和CPU都使用它們自己的虛擬地址空間，從而導致許多額外的開銷，UVA的引入為GPU之間的點對點數據傳輸提供了邏輯支持，使得開發者體驗到更方便的內存管理。如圖1所示為多存儲器模型和統一地址空間模型的結構圖。

3.2CPU中轉傳輸在CUDA3.2及其之前的版本中，多GPU的設備存儲器和主機端的內存被視為獨立的存儲器塊，各自擁有獨立的地址空間。GPU之間如果需要進行通信的話則必須首先通過將數據從GPU端拷貝到主機端內存，再由主機端內存傳輸至目標GPU中的顯存。

3.3GPU點對點傳輸在CUDA4.0之前的多GPU程序開發中，每個GPU被看成是獨立的核心。而在CUDA4.0中，每顆核心及其具備的各種存儲資源被當做一個整體的工作網絡中的結點，各個節點之間的通信和同步是對等的（形成了一個共享式內存的SMP網絡）。host端的內存資源和GPU上的設備存儲資源被當做一塊統一的存儲器池，存儲器地址統一編碼，多GPU之間可以通過PCI-E總線直接進行通信，而不再需要通過內存進行中轉。

3.4結果預測雖然GPU之間的直接數據傳輸直接繞開了主機端內存的中轉，但由于基于Fermi架構的顯卡沒有對GPU之間的數據傳輸提供直接的硬件支持，在數據傳輸時仍然需要將數據經由總線，其實質是少了一次經由PCI-E總線的數據傳輸的時間。因此預測隨著計算規模的增大，G_G（GPU點對點傳輸）相對與G_H（CPU中轉傳輸）的傳輸方式的計算時間差應該有所提升，提升的速度應該基本呈線性增長的趨勢，其時間差應與數據的規模成正比，與總線帶寬成反比。以矩陣復合運算A*B+C*D為例，在一定的數據規模下，設GPU的矩陣計算時間為0T，將四個矩陣拷貝至4個GPU的總時間為1T，將計算結果拷貝回CPU端的時間為2T，單GPU對中間結果的單向數據傳輸時間為T，則G_G的理論計算時間為012T+T+T+3T，G_H的理論計算時間為012T+T+T+8T，時間差為5T。這是因為，G_H采用的是4塊GPU全部將數據傳輸至CPU，再從CPU中轉至其中的一塊GPU（如GPU0），總計算時間為012T+T+T+8T。而G_G則不然，這是因為GPU0在計算加法運算之前需要進行(A/2)*B，而計算結果并不需要進行傳輸，直接駐留在GPU0中，因此中間結果不僅繞開了主機端的參與，同時也省略了(A/2)*B的兩次數據傳輸。在本文中，我們設計的矩陣中的數據類型是單精度的浮點數float，如果在GPU中分配和C/2和D同樣大小的數據，采用CUDA4.0SDK中的simpleP2P樣例來測試GPU之間的數據帶寬（實際上就是PCI-E的實際帶寬），則數據總量與PCI-E總線實際帶寬的商1T應該與T在理論上相等。

4實驗結果與性能分析

4.1實驗環境實驗所用平臺的參數如表1所示。

4.2域間通信方式選擇本節從通信策略支持的通信方向、對標準協議（TCP、UDP）的支持、延遲以及對用戶的透明性等角度來分析在基于Xen的虛擬化環境下不同的通信策略對CUDA應用的性能影響。盡管XenSocket和XWAY能夠在基于Xen的虛擬化平臺下提供高效率的域間通信，但是這些通信機制都存在某方面的不足。從客戶端和服務的通信方向、對標準協議的支持、TCP提交的延遲（單位為TCP報文的往返時間）以及對用戶的透明性對三種通信方式進行比較。從表2可見，XenSocket的功能比較簡單，只支持單向通信，而傳統的socket通信和RPC都是雙向的，這就使得其無法充分利用RPC機制的透明性。由于它的立足點在于增加虛擬機域間的傳輸帶寬，對標準的TCP和UDP協議的支持也不完善。同時，XenSocket雖然在數據量少（一般在16KB以下）時的單向吞吐量是XenLoop的兩倍多，但由于其采用固定的緩沖區大小使得其無法滿足更大數據量的傳輸需求。XWAY通過攔截socket底層的TCP調用來為面向TCP連接的應用提供透明的虛擬機域間數據傳輸。但它同樣存在諸多不足，如它需要對網絡協議棧進行修改、不支持UDP協議、不支持套接字的在線遷移，同時，XWAY也未對共享內存的安全性進行考慮。XenLoop方案對用戶和系統都是完全透明的，提供了高性能的虛擬機域間網絡回環通道。它支持TCP和UDP兩種協議，同時利用Xen提供的授權表機制在數據通道的兩端建立共享緩沖，實現全雙工通信，并實現了對共享區的同步機制和安全機制。本文將在Xen平臺下使用XenLoop加速虛擬間的通信。由于VMware的閉源性，在學術界很少有基于VMware虛擬化平臺的通信解決方案。但VMware公司開發了一套相應的虛擬機通信接口VMCI，它是一個工作在應用層的解決方案，提供在VMware系列虛擬機平臺（Workstation、ESXi等）下的快速、高效的域間通信通道，使得客戶虛擬機與客戶虛擬機、客戶虛擬機與宿主虛擬機之間能夠高效的通信。本文在VMware虛擬化系列平臺下均采用VMCI進行域間加速。

4.3GPU內部數據傳輸由于受計算機計算能力和內存容量方面的限制，很多并行程序對數據進行拆分并通過數據交換來實現原來程序的功能。在本文中我們通過矩陣復合運算A*B+C*D來完成整個實驗數據的驗證。A*B+C*D，其中A*B分別由device0和device1完成，C*D分別由device2和device3來完成，乘法完成后通過兩種方式分別將計算結果傳遞給device0，由于矩陣加法的復雜度較低，所以在最后所有的加法運算全部交由一塊GPU來完成。本節給出了4個GPU在兩種不同數據傳輸方式下的性能比較。表3所示為G_H和G_G隨著矩陣規模逐漸增大后的統計特征對比，統計特征包括kernel函數的迭代次數、實驗方差。在表3中，kernel執行次數即在主函數中執行kernel的次數，也即迭代次數。方差則表示若干次迭代次數的時間的統計方差，單位為秒的平方（2s）。圖2所示為通過兩種數據傳輸方式的時間對比，橫軸是矩陣的階數，縱軸是執行的時間。為了使最后統計的數據統一，圖中的執行時間均為將迭代次數換算至100次后的時間，同時，矩陣復合運算的執行時間是輸入數據初始化完畢后開始計時，數據從GPU端拷回主機端結束計時，因而未將由于虛擬化帶來的性能開銷（即訪問延遲）考慮在內。從圖4中可以看出，隨著矩陣規模的增加，G_H相對于G_G的執行時間差也越來越大，變化速度基本呈線性增長的態勢。由3.4節的理論分析知，這是由于G_G相對于G_H少了5T，其中T為單GPU對中間結果的單向數據傳輸時間。G_G相對于G_H不僅少了中間結果在總線上一次數據傳輸，同時GPU0在計算加法運算之前進行(A/2)*B的計算結果并不需要進行傳輸，直接駐留在GPU0中，因此中間結果不僅繞開了主機端的參與，同時也省略了(A/2)*B的兩次數據傳輸。表4所示為實際測量的時間差與理論計算值對比情況。其中，理論值為單個GPU傳輸(C/2)*D的結果乘以系數5后的結果；測量值為在主機端生成同理論值相同數據量的數據將其傳輸至GPU中所花費的時間乘以系數5后的結果；實際值即如圖4中的G_H和G_G的時間差；實際-理論差即為理論計算值與G_H和G_G時間差的差值；同理，測量實際差為“等價”的測量值與實際的時間差的差值。由表4不難看出，理論值、測量值與實際值基本相符，同時隨著矩陣的階數不斷增加，實際理論差有著小幅度的增加，但都在允許的測量誤差范圍之內。測量實際差基本上為0，這是由于測量的數據和實際傳輸的數據在格式和規模上完全一致，只是簡化了數據傳輸的過程。圖4和表4驗證了3.4節結果預測的正確性。

5結束語

本文對現有的虛擬機域間通信的優化方案分進行詳細介紹，通過對比幾種優化方案，在Xen平臺下采用XenLoop域間通信方式為GPU虛擬化環境下的最優通信方式，在VMware虛擬化平臺下使用VMCI的通訊方式。在單節點多GPU內部通信方面，設計了兩種方式（G_G和G_H）完成GPU間的數據傳輸，以矩陣復合運算為應用場景設計了實驗，結果驗證了預測結果的正確性。將來的工作將是對于在集群環境下，GPU虛擬化的數據傳輸問題的分析。

作者：張玉潔 呂相文 張云洲 單位：南京航空航天大學計算機科學與技術學院