T級內存,t級內存需要什么主板

T級內存

簡介：阿里云工程師李偉男和郭成在KVM Forum 2020上詳細介紹了阿里云KVM虛擬機創建及啟動時間優化的具體技術實現，本文根據其演講整理而成。

對于云計算用戶來說，過長的KVM虛擬機創建及啟動時間非常影響體驗，特別是超大規格的KVM異構虛擬機。以350G內存為例，創建時間需要2分鐘，當用戶此時創建虛擬機是用于快速恢復業務時，2分鐘的創建等待時間完全超出用戶的可忍受值。另外，對于云計算的后臺管控系統而言，過長的阻塞時間極大地影響了系統調度效率。

一直以來，阿里云異構計算團隊在KVM性能優化方面都有大量的投入，積淀了大量實戰經驗。阿里云異構計算團隊創新性地提出了一種顯著優化帶有透傳（passthrough）設備的KVM虛擬機創建及啟動時間的方法，虛擬機的啟動時間不再隨著分配內存的大小而顯著增加，即使虛擬機被分配了幾百G甚至更多的內存，用戶感知的啟動時間依然沒有明顯增加。

在這套技術優化方案下，對于350G內存的虛擬機，創建及啟動時間可從原來的120秒以上降低到20秒以內，效率整整提升了6倍以上；對于T級內存的虛擬機，預計創建效率可以提升10倍以上。

作為KVM社區最為重要和權威的大會，KVM Forum 2020有3個議題是與KVM虛擬機創建及啟動速度的優化有關，分別來自阿里巴巴、英特爾和滴滴，可見KVM社區及云計算業界對此問題的重視程度。阿里云工程師李偉男和郭成在KVM Forum 2020上詳細介紹了阿里云KVM虛擬機創建及啟動時間優化的具體技術實現，本文根據其演講整理而成。

1、發現問題：內存越大、啟動越慢，DMA map執行是耗時大戶

眾所周知，PCI設備透傳是KVM虛擬化應用中一個非常重要的場景，而VFIO是當前最為流行的PCI設備透傳解決方案，為了能夠在應用層提供高效的DMA訪問，在啟用VFIO設備之前，需要將分配給虛擬機的所有內存都鎖定并進行IOMMU頁表的創建。

這么做的原因在于，DMA訪問可能覆蓋整個虛擬機的內存空間，并且DMA訪問的內存不能被換出（swap）。所以，如果能夠在物理設備DMA訪問之前得知將要訪問的地址空間，就可以在運行中進行內存鎖定（pin）及IOMMU頁表的創建。但目前并沒有一個簡單、高效的方法能夠完成這一操作。為了虛擬機及設備的高效運行，目前開源社區采取的辦法是在虛擬機創建時將所有分配給它的內存進行鎖定并創建IOMMU頁表（DMA map）。

由于DMA map是一個相對比較耗時的操作，在虛擬機內存相對較小時，總體耗時是可以接受的。但隨著虛擬化市場及技術的發展，越來越多的用戶開始使用超大規格的虛擬機，內存資源已從4G增長到384G甚至更高，隨之帶來的DMA map時間消耗問題也日益突出。

圖1:虛擬機的創建及啟動時間與內存大小關系

如圖1所示，以開源社區的KVM虛擬化組件及Ubuntu18.04虛擬機為例，在虛擬機內存達到350G以上時，整個KVM系統的啟動時間將超過2分鐘，其中絕大部分時間都消耗在DMA map執行操作中。在這2分鐘里，對于用戶來說虛擬機是一個黑盒，用戶能做的只有靜靜等待，甚至不確定虛擬機是否仍然在正常創建中，完全處于未知的狀態。

2、設計思路：異步DMA map，完美解決虛擬機創建耗時問題

為了解決這一個問題，阿里云異構計算團隊研究了現有的虛擬化技術和實際應用場景。雖然DMA map本身不能省去，但我們發現在系統啟動過程中DMA訪問雖然是隨機的、但并不會訪問到全部，由此阿里云異構計算團隊提出了一種異步DMA map（async DMA map）的方法，即在虛擬機創建過程中僅map有限的內存空間，剩余的大部分內存空間可以在虛擬機啟動過程中于后臺異步map完成，從而保證用戶可以快速地獲取訪問虛擬機的權限。

這時，如何保證虛擬機在啟動過程中不會有設備通過DMA訪問到需要異步map的內存就成為了關鍵。這個過程中，我們用到了大家比較熟悉的Virtioballoon，因為Virtioballoon設計之初即被用來占用虛擬機內存使用，因此我們提出的解決方案不會涉及到大量、復雜的軟件改動，即可完美解決虛擬機創建耗時的問題。

圖2:async DMA map設計思路

Async DMA map主要設計思路就是：虛擬機創建時，低于4G內存空間的DMA map請求會被正常處理，其他內存空間的DMA map操作將會等待virtioballoon前端驅動加載完成后根據實際情況進行處理。

具體的操作流程如下：

首先，確保virtioballoon驅動先于VFIO設備驅動加載。這樣virtioballoon驅動會在配置空間中獲取初始的balloon大小，然后再根據balloon大小進行實際的虛擬機內存的分配，被分配的內存將從可用內存中去除。在沒有釋放前，其他設備將無法申請到這部分被占用的內存，那就不會被DMA訪問到，也就不需要在這之前進行map。

其次，完成balloon，獲得可異步執行map內存空間。Balloon的過程是經過很多次inflate操作完成的。每次操作完成后，前端的virtioballoon會通知后端完成的inflate balloon大小及其對應的PFN，位于宿主機上的后端驅動收到通知后，會將PFN從消息隊列中解析出來，并轉換為IOVA記錄在ballooned頁表中。待balloon完成后，后端驅動會得到一張完整的被virtioballoon占用的內存頁表，這部分的內存空間即是可以異步執行map的部分。沒有在頁表中的內存可能會被其他設備通過DMA訪問，因此需要即刻完成map操作。

最后，在保證虛擬機系統可繼續正常啟動的情況下，async DMA map正式開始。通過向virtioballoon前端驅動觸發deflate操作，從而向虛擬機歸還一定大小的內存，前端virtioballoon驅動會將釋放的內存地址同步給后端驅動，后端驅動接收到被釋放的內存地址空間后，觸發同步的DMA map，通過分步的deflate及map，慢慢完成全部內存的映射、鎖定，從而使虛擬機恢復到完整內存資源可用狀態。

3.具體實踐：三個關鍵點優化，進一步優化啟動時間

在具體的實踐中，我們進行了balloon臨近地址空間自動合并、增加單次balloon頁面大小和預處理機制等三個關鍵點的優化，以進一步優化啟動時間。具體優化如下：

（1）Balloon臨近地址空間自動合并。通過合并多次balloon的臨近內存地址空間，可以顯著地減少觸發DMA map的次數。因為virtioballoon會在系統啟動初期被加載，此時的內存使用較少，virtioballoon申請到的內存地址絕大部分是連續的，臨近內存地址的可合并率非常高。

（2）增加單次balloon頁面大小。內存資源已經不再是非常稀缺的資源，當前virtioballoon前端驅動中基于小頁（4KB）大小的內存申請機制已經不太適合當前大規格實例的業務場景。基于業界用戶實際應用場景的分析，我們將virtioballoon單次申請的內存大小從4KB提高到2MB，這一舉措可減少約98%的前后端通信消耗，從而顯著減少了不必要的CPU資源占用。

（3）預處理機制。為了更快的完成異步DMA map操作，其實可以預先開始進行DMA map操作，而不是等待deflate觸發并收到virtioballoon前端驅動發出的通知才進行。在接收到前端發出的通知后，只需要做釋放地址已映射命中檢測即可。如地址未命中則可以插入DMA map操作，若命中則可以更快地返回通知給虛擬機進行后續的deflate操作。

圖3：VM啟動時間與內存關系（左）、QEMu初始化時間與內存關系（右）

如圖3，經過上述的優化（初始保留8G內存給虛擬機），我們看到隨著分配給虛擬機的內存增加，KVM虛擬機的啟動時間及QEMU初始化時間均沒有明顯增加。即我們將350G內存KVM虛擬機的創建及啟動時間從原來的120秒以上減少到20秒以下，QEMU初始化時間縮減到7秒以內。對于T級內存的用戶，預計效率可提升10倍以上，可以極快地獲得虛擬機的訪問控制權限。

結語

未來，我們將持續依托阿里云智能，致力于云計算產品的性能及用戶體驗的優化，為用戶提供便捷、高效的彈性計算產品。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。