iT邦幫忙

2021 iThome 鐵人賽

DAY 21
0
Software Development

閱讀 Linux Kernel 文件系列 第 21

# Day 21 Heterogeneous Memory Management (HMM) (一)

  • 分享至 

  • xImage
  •  

今天來看看在 # Day 18 Physical Memory Model (三) 的文件中提到的 HMM!
在要求效能又要求功耗的現今,異質運算系統是一個很熱門的研究和實作方向;
筆者在碩士班期間加入的實驗室,也是在做相關的研究,想方設法的結合 CPU 和 GPU 的運算能力,來實現一個高效能的系統;
這份文件描述的就是 kernel 中提供的異質系統下記憶體管理的基礎設施 (facility),直接看下去吧!

文件

.. _hmm:

===================
異質記憶體管理 (HMM)
===================

提供基礎設施和輔助函數來整合非傳統記憶體
(裝置上的記憶體,例如 GPU 上的記憶體)
至一般的核心執行路徑,
以特規化的 struct page 作為此類記憶體的基石。
(參見本文件第 5 至 7 節)

HMM 也為 SVM(共享虛擬記憶體)提供了可選擇的輔助函數,
即,允許裝置存取程序的定址空間,
意味著任何對 CPU 是有效的指標,對於裝置也會是有效的。
這對於簡化進階的異質架構,
包含使用 GPU、DSP、FPGA 來為程序做各式各樣不同的運算,
已經是個必要的存在。

本文件分為以下部分:
在第一部分中揭露了和使用特定於裝置的記憶體分配器的相關問題。
在第二部分,提到了許多平台天生的硬體限制。
第三部分描述了 HMM 設計概觀。
第四部分解釋 CPU 分頁表的鏡像是如何運作的,
並且在其中使用 HMM 的目的。
第五部分涉及在核心中,裝置的記憶體是如何表示的。
最後,最後一節介紹了一個新的轉移輔助函數,
它能夠利用裝置的 DMA 引擎。

.. contents:: :local:

使用裝置特定記憶體分配器的問題
============================

具有大量板載記憶體(幾 GB)的裝置,如 GPU
從過去就一直透過專用的驅動程序 API 來管理它們的記憶體。
這會造成裝置驅動程序分配和管理的記憶體和一般應用程序的記憶體 
(私有匿名的、共享記憶體或是一般檔案備份的記憶體) 之間有斷層。
從這裡開始,我將把這部分稱為拆分的定址空間。
並使用共享定址空間來指稱相反的情況:
即,裝置可以使用任何應用程序的記憶體區域。

拆分的定址空間是因為裝置只能存取專用的
裝置 API 所分配的記憶體而產生。
這意味著程序中的所有記憶體物件
和從裝置的角度來看是不對等的,
而這使得使用廣泛函式庫的大型程序變得更為複雜。

具體來說,這意味著想要利用像 GPU 等裝置,
程式碼需要在一般分配的記憶體 (malloc、mmap private、mmap share)
和通過裝置驅動 API 分配的記憶體之間複製記憶體物件。
(這仍然是使用 mmap 但是是在裝置文件上)。

對於扁平的資料集合(陣列、網格、圖像等),這並不難實現,
但是對於複雜的資料集合(列表、樹狀結構等),則很難做到正確。
複製一個複雜的資料集合,
需要重新映射其每個元素之間的所有指標關係。
因為這些重複的資料集合和位址,使得程序很容易出錯並且更難除錯。

拆分的定址空間也意味著,函式庫不能直接使用
從主要程序或是其他函式庫所取得的資料。
因此每個函式庫可能必須使用特定於裝置的記憶體分配器來複製其輸入資料。
大型專案受此影響困擾,也因為各種記憶體副本浪費資源。

複製每個函式庫的 API 來實作
以接受由裝置特定的分配器所分配的輸入或輸出記憶體,
不是一個可行的選擇。這將導致一個函式庫的入口點有爆炸多的組合。

最後,隨著高級語言結構的進步(在 C++ 中,在其他語言也有)
現在編譯器可以利用 GPU 和和其他裝置,在程式設計師不知情的情況下。
一些編譯器識別的模式只能使用在共享定址空間。
對於所有其他模式,使用共享定址空間也比較合理。

我的理解

目前閱讀的部分,提到了這份文件的架構以及第一節的使用特定於裝置記憶體分配器的問題。
其實還稍微有些感覺呢,大部分有稍微使用過 CUDA、OpenCL 框架,或是任何異質裝置管理框架的讀者想必對這個議題都不陌生!
在使用實際裝置來做運算之前,要先使用裝置驅動程式相關的 API,例如:CUDA 上的 cudaMalloc 來取的一塊裝置上的記憶體,接下來使用 cudaMemcpy 將 host 上的資料傳到 GPU 上,進行運算後,再將 GPU 上運算過後的資料複製回 host 上,才算真正的完成一次運算並且得到資料;有時候在 GPU 的加速之下,甚至會看到複製資料使用的時間還比實際運算的時間來的長!
也許這個 HMM 會是一個可以稍微緩解這個問題的技術噢!那麼我們明天繼續一起看下去吧!
(( p.s. 雖然現在看起來 CUDA driver 是還沒有支援 HMM XD 連結

後記

transparently 和 coherently 要怎麼翻啊?XD
transparently 應該是指"透明的",有一種不會影響到其他、或是不會被感知到的感覺。
coherently 是指會看到一致性的資料,的那種感覺吧!XD

參考資料

延伸閱讀


上一篇
# Day 20 High Memory Handling
下一篇
# Day 22 Heterogeneous Memory Management (HMM) (二)
系列文
閱讀 Linux Kernel 文件30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言