今天繼續來看 HMM 的後續！
輸入輸出匯流排、裝置記憶體特性
===========================
由於某些限制，
輸入輸出匯流排使共享定址空間無法使用。
大多數輸入輸出匯流排
從裝置對主記憶體只允許做基本的存取；
甚至快取一致性通常都是選配的。
而從 CPU 存取裝置記憶體甚至有更多的限制。
且通常不是快取一致的。
如果我們只考慮 PCIE 匯流排，
那麼裝置可以存取主記憶體
（通常是透過 IOMMU）並與 CPUs 保持快取一致。
然而，它在主記憶體上只允許來自裝置的一些原子操作。
更糟的是在另一個方向：
CPU 只能存取有限範圍的裝置記憶體
並且不能對其執行原子操作。
因此從核心的角度來看，
裝置記憶體並無法被認為和一般記憶體相同。
另一個因素是有限的頻寬
（PCIE 4.0 和 16 通道約 32GBytes/s ）。
這比最快的 GPU 記憶體 (1 TBytes/s) 少 33 倍。
最後一個限制是延遲。從裝置存取主記憶體
與裝置存取自己的記憶體相比，延遲要高出一個數量級。
一些平台正在開發新的輸入輸出匯流排
或對 PCIE 做些增強/修改來解決其中一些限制（OpenCAPI、CCIX）。
他們主要想達到 CPU 和裝置之間有雙向的快取一致性，
並能使用所有架構支援的原子操作。
但可惜的是，並非所有平台都遵循這樣的趨勢，
且一些主流架構並沒有這些問題的硬體解決方案。
因此，要使共享定址空間能運作，
我們不僅必須讓裝置能夠存取任何記憶體，
我們還必須使任何記憶體，
當裝置正在使用的時候，都能被遷移到裝置上
（在遷移發生時阻擋 CPU 存取）。
共享定址空間和遷移
=================
HMM 打算提供兩個主要功能。
第一個是共享定址空間，
透過複製 CPU 的分頁表到裝置的分頁表，
使得在裝置定址空間中，
對任何有效的主記憶體位址，
都是具有相同的位址指向相同的實體記憶體的特性。
為了實現這一點，
HMM 提供了一套輔助函式來填充裝置的分頁表，
同時紀錄 CPU 分頁表的更新。
裝置的分頁表更新並不像 CPU 分頁表更新那麼容易。
要更新裝置分頁表，您必須先分配緩衝區（或使用預先分配的緩衝區池）
並寫入 GPU 特定的指令來執行更新（unmap, cache invalidations, and flush ...）。
並不能透過使用通用程式碼來為所有裝置完成這些。
因此這是 HMM 提供輔助函式來執行所有的通用部分，
並留下硬體相關的細節來給裝置驅動程式做處理。
HMM 提供的第二個機制是一種新的 ZONE_DEVICE 記憶體，
允許為裝置記憶體的每個分頁分配一個 struct page。
這些分頁是特殊的，因為 CPU 無法映射它們。
但是，是可以使用現有的遷移機制，從主記憶體遷移到裝置記憶體上，
而從 CPU 角度來看，一切就像是分頁被置換到硬碟上。
使用 struct page 提供了最簡單和最乾淨的方式與現有 mm 機制整合。
再一次，HMM 只提供輔助函數，
先熱插拔新的、用於裝置記憶體的 ZONE_DEVICE 記憶體；
再來，執行遷移。
決定遷移的內容和何時遷移的方針則由裝置驅動程式決定。
請注意，任何 CPU 對裝置分頁的存取都會觸發分頁錯誤
和遷移回到主記憶體。
例如，若儲存給定 CPU 位址 A 的分頁從主記憶體分頁被遷移到裝置分頁，
那麼任何 CPU 對於位址 A 的存取將會觸發分頁錯誤並啟動遷移回到主記憶體。
有了這兩個特性，HMM 不僅可以讓裝置鏡像程序的定址空間、
保持 CPU 和裝置分頁表同步，
並且透過遷移部分裝置正在使用的資料來利用裝置的記憶體。
今天閱讀的文件內容描述了：
看完這邊在反過來想，為什麼會需要 shared address space，就發現昨天讀的第一節就是在描述 split address space 的一些不理想之處，需要透過 driver specific memory allocator 來分配記憶體。
有了 shared address space 就沒有這個煩惱了！
明天接著來往下看，看看 HMM 提供的 shared address space 和 migration 是怎麼實作的！
iThome鐵人賽
看影片追技術