LWN：針對direct-map碎片的解決方案！

關(guān)注了就能看到更多這么棒的文章哦～

Solutions for direct-map fragmentation

By Jonathan Corbet
May 12, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/894557/

內(nèi)核的 "direct map" 機制使一個系統(tǒng)的全部物理內(nèi)存都可以在內(nèi)核的虛擬地址空間中使用。通常情況下，會使用 huge page 來做這種映射，這使得訪問 direct map 的時候更加高效。但是，越來越多的人需要從 direct map 中分割出一些 page；這就把這些 huge page 給打散了，使得整個系統(tǒng)的效率降低。在 2022 年 Linux 存儲、文件系統(tǒng)、內(nèi)存管理和 BPF 峰會（LSFMM）的內(nèi)存管理會議上，Mike Rapoport 主持了一個關(guān)于 direct-map fragmentation 以及如何避免這種碎片的會議。

Rapoport 首先說，direct map fragmentation 問題目前只在 x86 架構(gòu)上有需要。因為其他一些架構(gòu)根本無法對 direct map 進(jìn)行打碎使用。很多事件會導(dǎo)致 direct map fragmentation，比如 BPF program 的分配，各種秘密的內(nèi)存機制（https://lwn.net/Articles/865256/ ），以及像 SNP 和 TDX 這些虛擬化技術(shù)。未來預(yù)計還會有，包括 permission vmalloc() API 以及使用 protection keys supervisor (PKS) 來保護(hù) page table，這都會使事情變得更糟。隨著更多的子系統(tǒng)從 direct map 中分割出一些碎片區(qū)域，系統(tǒng)的性能就會下降；這需要盡量避免。

Rapoport 的建議是將這些不同的用途都匯聚到一個獨立的內(nèi)存區(qū)域中，從而盡量減少它們所產(chǎn)生的碎片。一旦一個 huge page 被分割出來使用了，那么后續(xù)就應(yīng)該盡可能把接下來的對這類內(nèi)存請求都用這一個 huge page 來滿足。為此，他建議新增一個 GFP flag（__GFP_UNMAPPED），這樣一來，就可以使用通常的 page allocator 調(diào)用來獲取到已經(jīng)從 direct map 區(qū)域中刪除掉的內(nèi)存。使用這個 flag 的代碼就需要自己按他們的需求來對這部分內(nèi)存進(jìn)行 map。還有新增一個遷移類型（MIGRATE_UNMAPPED）將被添加，以避免這些內(nèi)存意外地遷移回 direct map 的內(nèi)存中。他已經(jīng)發(fā)布了一組 patch set，按照這個想法實現(xiàn)了此原型。他說，這個補丁 "基本可以用"。

Michal Hocko 說，使用 page allocator 可能不是最好的方法。因為這會給極少數(shù)情況下的那些已經(jīng)進(jìn)行過極致優(yōu)化的快速路徑增加了額外開銷。Mel Gorman 同意，使用 page allocator 應(yīng)該算是矯枉過正，為單個使用場景創(chuàng)造了一個特殊情況。他補充說，Rapoport 增加了一個單獨的遷移類型，這最終會導(dǎo)致內(nèi)存碎片化，因為這些 page 不能被移動了。Rapoport 回答說，在一個長期運行的機器中，direct map fragmentation 是不可避免的，于是 Gorman 回答說，他不希望看到在 page allocator 上增加額外復(fù)雜性來解決一個仍然會發(fā)生的問題。

Rapoport 說，一個替代方案是在 page allocator 之外設(shè)立一個并行的分配機制。在這種情況下，每個用戶都會有自己的 cache，這個方案不太有吸引力。但是 Gorman 回答說，遷移類型（migration type）也不是沒有開銷的；每個新增的遷移類型都會增加一組鏈表，并增加了 page-block bitmap 的 size。他說更好的解決方案可能是使用一個專門 slab cache。

David Hildenbrand 說，在他進(jìn)行 memory hotplug 工作時，他討厭那些不可移動的內(nèi)存；Rapoport 的提案將創(chuàng)造出更多的不可移動的內(nèi)存，使問題變得更糟。Rapoport 說，他的 patch 在進(jìn)行 unmapped allocation 時會盡量避免使用 movable zone，這應(yīng)該會使影響最小化。不過，Hocko 重申，page allocator 并不是進(jìn)行這種分配的最佳場所；用戶對內(nèi)存分配過程會 "在乎每一個 CPU cycle"，在那里增加任何額外開銷都是不受歡迎的。他說，最好是在 page allocator 的基礎(chǔ)上建立一個類似 slab allocator 的機制。

在會議結(jié)束時，Rapoport 說，他將嘗試創(chuàng)建某種類似 slab 的解決方案。Vlastimil Babka 提醒說，現(xiàn)有的 slab allocator 無法用于 BPF 程序。slab allocator 發(fā)放出來的對象都是有一樣的 size 的，但每個 BPF 程序都希望有差異。Rapoport 最后說，他不確定如何解決所有的問題，但會很快進(jìn)行嘗試。

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

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