LWN：用 msharefs 共享頁表！

關注了就能看到更多這么棒的文章哦～

Sharing page tables with msharefs

By Jonathan Corbet
July 15, 2022
DeepL assisted translation
https://lwn.net/Articles/901059/

頁表項（PTE, page-table entry）本身相對較小，在大多數(shù)系統(tǒng)上只需要 8 個字節(jié)就可以指向（refer to）一個 4096 字節(jié)的 page。因此，看起來它帶來的開銷并不怎么讓人擔憂，而且歷史上來說內核幾乎沒有費力去減少頁表的內存消耗。但是，如果這 8 個字節(jié)的方案被復制來支持非常多的進程時，就會帶來較大的損失了。來自 Khalid Aziz 的 msharefs 這個 patch set 就是解決這個問題的一個修改方案，但是它在內存管理社區(qū)看起來很難被接受。

在 Linux（也包括其他大多數(shù)操作系統(tǒng)）上，一個進程的決定性特征之一就是有一個獨立的地址空間。因此，管理該地址空間狀態(tài)的 page-table 對每個進程來說都是私有內容（盡管一個進程中的線程還是會共享頁表的）。因此，如果兩個進程對物理內存中的同一個 page 都有映射，那么每個進程都有一個獨立的 page-table entry 來管理這個 page。因此，PTE 的開銷會隨著映射每個 page 的進程的數(shù)量而線性增加。

盡管如此，這種開銷通常不算是什么問題，但這世界上總有一些人在做一些離奇的工作。正如這組 patch 的 cover letter 中所述：

在一個擁有 300GB SGA [Oracle 系統(tǒng)全局區(qū)域，https://docs.oracle.com/database/121/ADMQS/GUID-A3319550-AB7A-4429-9A58-4B90E4B3D0F5.htm] 的數(shù)據(jù)庫服務器上，當 1500 多個客戶試圖共享這個 SGA 時，盡管系統(tǒng)擁有 512GB 的內存，卻還是出現(xiàn)了系統(tǒng)崩潰的情況。在這臺服務器上，在最壞的情況下，所有 1500 個進程映射 SGA 中的所有 page 的話就需要 878GB 以上的空間來存放 PTE 了。如果這些 PTEs 可以被共享，那么可以節(jié)省海量內存。

因此這個工作的目標就是能讓這些 PTE 共享，這一點在 5 月份的 Linux 存儲、文件系統(tǒng)、內存管理和 BPF 峰會上討論過。當時，Aziz 提出了一個新的系統(tǒng)調用（mshare()）來管理這種共享。目前的 patchset 已經(jīng)修改了接口，現(xiàn)在根本不需要新的系統(tǒng)調用了。

即使沒有新增系統(tǒng)調用，這些進程仍然需要有辦法來明確請求把特定范圍內存的頁表進行共享。目前的 patch set 提供了另一個內核虛擬文件系統(tǒng) msharefs 來實現(xiàn)這個目標；這個文件系統(tǒng)需要被掛載在/sys/fs/mshare。讀取該文件系統(tǒng)中的 mshare_info 文件就可以得知要讓內存區(qū)域能夠共享頁表所需的最小 alignment 需求。

下一步是在/sys/fs/mshare 下創(chuàng)建一個文件，這個名稱應該是根據(jù)相關應用程序來的。然后，使用 mmap() 調用將該文件映射到進程的地址空間里。傳遞給 mmap() 的 size 會決定內存共享區(qū)域的 size。編者閱讀代碼的理解是，最好在映射時提供一個明確的地址，目前似乎沒有自動機制來幫助選擇符合 alignment 要求的地址。在該區(qū)域被映射之后，就可以像其他內存范圍一樣直接使用了。

創(chuàng)建這樣的區(qū)域的目的是為了讓其他進程也能對它進行映射。其他任何進程都需要從打開第一個進程創(chuàng)建的 msharefs 文件開始，然后從中讀取出這樣的一個結構：

struct mshare_info {
  unsigned long start;  unsigned long size;};

start 和 size 字段分別提供了區(qū)域被映射到的地址和 size 信息；新進程應該將這些值（以及打開的 msharefs 文件）傳遞給它自己的 mmap() 調用來對共享區(qū)域進行 map。之后，該區(qū)域就像是跟其他共享內存區(qū)域一樣進行映射的了，但還是有幾個重要的差異，將在下面描述。

一個進程的地址空間是由 mm_struct 結構所描述的；系統(tǒng)中的每個進程（除內核線程外）都有一個這樣的結構。msharefs patchset 通過為每個共享區(qū)域來創(chuàng)建一個新的 mm_struct 結構，從而改變了這個結構和其所屬進程之間一直以來沿襲的一一映射的關系。用來描述這個區(qū)域的 page table 屬于這個獨立的結構，而不是屬于任何進程的 mm_struct。每當一個進程要映射這個區(qū)域時，相關的 vm_area_struct（VMA）將包含一個指向這個特殊 mm_struct 的指針。最終結果是，所有映射這個區(qū)域的進程不僅共享內存，而且還共享與之相關的頁表。

當然，這節(jié)省了原本用于存放重復頁表的內存，但這樣做也會帶來一些其他令人驚訝的結果。例如，用 protect() 改變該區(qū)域內存的 protection 情況，就會影響到所有共享該區(qū)域的進程；而對于普通的共享內存，只有調用者進程才會看到 protection 發(fā)生的變化。同樣，內存區(qū)域可以用 mremap() 來完全進行 remap，所有用戶都會看到這種變化。

看起來，使用 mremap() 實際上是 PTE 共享內存區(qū)域方案的預期效果之一。用來創(chuàng)建這個區(qū)域的 mmap()調用將用 anonymous memory 來 populate 這個區(qū)域；無法要求使用 file-backed memory。但是可以使用 mremap() 來把原始 mapping 都 dump 出來，并在之后替換成 file-backed memory。因此，應用程序如果想要同時使用 shared page table 以及 file-backed memory 的話，就不得不執(zhí)行這個額外的步驟來設置好。

在 LSFMM 會議上，開發(fā)人員明確表示看起來這整個方案有點可怕。到目前為止，對這組 patch 的回應（從內存管理的角度來看）相對比較少，只有 David Hildenbrand 例外，他正在推進另一種不同解決方案。他更希望看到一種機制，能在 mapping 被共享時就自動共享頁表，而不需要在應用層面進行修改。這種方案將可以使這個 sharing 帶來的好處能更容易地被利用，同時也暴露出更少的內存管理內部細節(jié)。

不過，自動共享需要有不同的語義（semantics）；否則，當另一個進程中的 mprotect()或 mremap()調用改變了這些 mapping 時，應用程序肯定會受到驚嚇的。雖然在 Aziz 的這一版本的 patch 中沒有說明，但從 LSFMM 會議上得到的感覺是需要來改變語義。如果是這樣的話，完全的自動共享將是不可能實現(xiàn)的，因為應用程序總是需要選擇是否允許這種行為。

不管怎么說，在進入 mainline 之前，這個特定的 patchset 需要更多的工作和討論。在那之前，依賴于在大量進程之間共享內存的應用程序將繼續(xù)為 page-table 支付高額成本。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關注，關注 LWN 深度文章以及開源社區(qū)的各種新近言論～