LWN：folio的最新情況！

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

A memory-folio update

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

folio 項目還不到兩年，但它已經(jīng)導致了對內核的內存管理以及文件系統(tǒng)層的重大改變。雖然已經(jīng)做了很多工作，但仍有不少尚未完成。在 2022 年 Linux 存儲、文件系統(tǒng)、內存管理和 BPF 峰會的開幕全體會議上，Matthew Wilcox 提供了關于 folio 遷移方面的最新情況，并主持了關于有待完成的工作的討論。

Wilcox 首先概述了 folio 的工作，更完整的描述可以在之前 LWN 文章中找到。簡而言之，folio 是一種表示一組物理上連續(xù)的 base page 的方式。它是對內存管理子系統(tǒng)中長期存在的混亂狀況的解決方法，一直以來， "page" 可能指一個 base page，也可能是一個更大的 compound page。添加一個新的術語可以消除 "page" 這個術語的歧義，并且簡化許多內存管理的接口。

除了讓術語定義更加明確之外，還有另一個動機來推動 folio 工作。內核確實需要用比 4KB base page 更大的單位來管理內存。即使在典型的筆記本電腦上也有數(shù)百萬個這樣的 page；這么多的 page 都需要管理，處理起來也很麻煩，造成了大量時間和精力的浪費。不過，我們需要更好的接口來利用更大單位的內存管理；folio 就是要成為這種更好的接口。

Current status

folio 是由 struct folio 表示的；它本質上是一個 compound page 的 head page 的別名。在過去的一年中，Wilcox 一直在向內核中添加使用 folio 的地方；這個項目已經(jīng)有了很大的進展，但還沒有完成。

有一個沒有答案的的問題是關于內核什么時候應該分配大的 folio，也就是那些包含一個以上 base page 的 page。現(xiàn)在只有 readahead 代碼會進行這種分配；文件系統(tǒng)的 write path 仍然以 base page 為單位來進行。如果要對通過 readahead 得到的 folio 進行寫入，他們會看到并使用這些 folio。不過，對文件的追加（append）將總是使用 base page。幾乎可以確定，在 write path 中使用大的 folio 是有好處的，但有必要弄清楚應該采用什么標準來創(chuàng)建它們。

同時，將文件系統(tǒng)代碼轉換為使用 folio 的過程仍在繼續(xù)。Wilcox 鼓勵文件系統(tǒng)開發(fā)者盡可能地尋找已經(jīng)存在的基礎設施，而不是自己重新實現(xiàn)它。他指出了最近由 David Howells 重寫過的網(wǎng)絡文件系統(tǒng)的支持層代碼。對于文件系統(tǒng)來說，如果能不再使用舊的 buffer-head API，盡可能使用相對較新的 iomap 的基礎設施，也是一件好事。

Ted Ts'o 說，在轉換到 iomap 方面如果能更多的指導，那會是非常有幫助的。他說，將一個文件系統(tǒng)遷移過來可能是一項艱巨的任務，但開發(fā)者應該都明白，這個任務是可以逐步完成的。例如，文件系統(tǒng)里的 read path 可以先被轉換過去，暫時不改變 write path。這個信息可能確實有幫助，Wilcox 同意，尤其是因為 iomap 仍然缺少一些功能，比如對 fs-verity 或壓縮等功能的支持。這些缺失在 write 方面往往比在 read 方面影響更大。

API complaints

Josef Bacik 說，Btrfs 的一個特別惱人的問題是，在獲取文件系統(tǒng)級的 lock 之前，必須先獲取內存管理子系統(tǒng)的 page lock。這在文件系統(tǒng)層面上很困難，并且阻礙了一些功能的實現(xiàn)，比如 range locking。他希望看到這個問題得到解決，但他也知道這并不容易。Wilcox 承認，這個問題根本不在他的考慮范圍之內，但他一定會去研究這個問題。Chris Mason 指出，這個問題并不是 Btrfs 所獨有的，其他文件系統(tǒng)多年來也遇到過類似的困難。

Bacik 還說，由內存管理來觸發(fā)的 page reclaim 也會有問題，而且文件系統(tǒng)的接口不是很好。他說，如果能夠將 "請釋放你現(xiàn)在能釋放的任何內存 "這樣的請求與釋放指定 page 的請求區(qū)分開來就好了。Wilcox 說，內核的許多回收機制可能不再適用了；它是在文件系統(tǒng)能力遠不如現(xiàn)在的時候設計的。現(xiàn)在好的文件系統(tǒng)已經(jīng)可以做到讓所有的驅動器都忙于 writeback 操作了；如果內存管理代碼要求文件系統(tǒng)代碼這邊把指定 page 釋放掉，其實文件系統(tǒng)能做的真的不多。他建議說，也許內存管理子系統(tǒng)應該簡單地停止要求回收那些已經(jīng)位于 LRU 列表末尾的 page。

他說，有一個可能的方法來測試這個想法；也許文件系統(tǒng)應該簡單地刪除他們對 writepage() 這個 address-space operation 的實現(xiàn)代碼。Howells 說，他已經(jīng)在 AFS 文件系統(tǒng)中這樣做了，結果似乎不錯。但其他一些文件系統(tǒng)比如說 9P，就比較困難了。

Ts'o 說，問題是內存管理子系統(tǒng)正試圖同時解決多個問題。當應對全局內存壓力時，它只需要釋放一些 page，并不會挑剔是哪里的 page。但是，一旦有 cgroup 牽涉進來，那么就必須要在相應的 container 內緩解內存壓力，這就要求內存回收需要更有針對性。在進行 compaction 壓縮來創(chuàng)建 huge page 時，就需要釋放指定的 page。這些情況都需要獨立地進行考慮。移除 writepage()可能有助于解決全局的問題，但釋放指定 page 的需求并沒有消失。

Wilcox 表示，希望廣泛使用大號的 folio 頁將至少有助于解決 compaction 問題，因為會有更少的內存碎片了。在一些 benchmark 測試中，他看到 LRU list 的長度減少了 1000 倍，這 "太瘋狂了（太棒了）"。

另一方面，他說，一個由大號 folio 導致的潛在問題可能是會有一些 write amplification （寫放大）。是否 dirty 這個狀態(tài)信息是在 folio 層面上來記錄追蹤的，而不是在其中所包含的具體某個 base page 層面上；當寫出數(shù)據(jù)的時候，即使只有一個字節(jié)發(fā)生了變化，整個 folio 也會被寫入。這將增加系統(tǒng)使用的寫入帶寬，但也應該有助于減少 copy-on-write 文件系統(tǒng)中的碎片化問題。他說，他預計不會有 "嚴重的麻煩"。

其他人就沒有他那么確定了。Mason 指出，Jens Axboe 已經(jīng)付出了相當大的努力，使在 io_uring 中進行小型操作（small operation）變得容易。這項工作主要是出于對 write-bandwidth 的擔憂。Axboe 補充說，帶寬確實會是一個問題，但在讀取方面比寫入方面的影響更大。對于這個問題究竟有多大影響，與會者進行了一些討論；一位開發(fā)者指出，具體情況會根據(jù)所使用的文件系統(tǒng)而有差異。對于一個具有高延遲的網(wǎng)絡文件系統(tǒng)來說，寫太多的數(shù)據(jù)可能比在服務器上做多次往返交互要更好。大家普遍認為，需要更好的衡量標準來正確理解這種情況。

Long-term goals

接著，Wilcox 說，他仍在把文件系統(tǒng)提供的 address-space operation 轉換為 folio 的過程中，還有幾處需要修改。在許多情況下，這種 "轉換" 只是改變一個函數(shù)原型，使其接受一個指向 folio 結構的指針，而不是指向 page 結構的指針，然后再增加一行代碼，比如：

struct page *p = (struct page *) folio;

他說，這種模式是 "聞起來不像是好代碼"；它能說明相關的代碼需要進一步的改動。我們的計劃是最終將每個文件系統(tǒng)都轉換為 folios，但不一定要使用大號的 folio。

這項工作背后有一個潛在動機：他希望最終能從 struct page 中刪除一個大的 union 成員，這需要文件系統(tǒng)都不再使用這個結構。他說，內存管理的開發(fā)者希望把更多的信息放到 struct page 中，但有很強的理由來阻止讓這個結構變得更大。因此，他想縮小這個 struct；也許有一天，它可以被減少（從 64 字節(jié)）到一個單個指針。更棒的是，這可能是指向 folio 的一個指針，而不是指向每個 page 的一個 structure，使內核能夠拿回目前用于容納 struct page 的 1.6% 的內存來作為其他用途。

他說，這將使公司能夠節(jié)省內存相關的開銷，并將其用于派遣他們的開發(fā)人員來參加更多的會議。

Howells 說，最終擺脫 write_begin() 和 write_end() 這些 address-space operation 就太棒了；Wilcox 同意，說它們最初是為 ext3 的需求而設計的，后來的文件系統(tǒng)也不得不適應這種模式。Goldwyn Rodrigues 指出，iomap 目前沒有使用這些 callback。

Kent Overstreet 抱怨不應該把包含 callback 的結構到處傳遞，他說這是 API 設計的 "舊的模式"。Bacik 說，他并不真正關心 API，只要它能讓他專注于 Btrfs，而不必擔心內存管理的運作就好。Wilcox 回答說，他的大部分工作都是為了使文件系統(tǒng)能更容易編寫，他希望 folios 能在這方面有所幫助。他說，文件系統(tǒng)中的任何東西都不應該關心 page，可能除了 page-fault 路徑的代碼之外。

不過，Overstreet 反對說，開發(fā)人員應該要更關心這些事情。內核的許多內部接口已經(jīng)嚴重老化了；開發(fā)人員應該討論痛點是什么，以及如何消除它們。Bacik 說，內核需要那些特別關心這些接口的開發(fā)者；他個人太疲憊了，無法承擔更多任務。因此，他很高興看到 folio 的工作；有一個關心接口的負責人，正在努力使它變得更好。他說，這是一項艱苦的、不辭辛勞的工作，并感謝 Wilcox 承擔了這項工作。

Wilcox 在會議結束時承認，folio 的工作給許多其他開發(fā)者帶來了額外的工作，并說他感受到了這些工作有多么繁重。開發(fā)者們已經(jīng)向他詳細說明了這些開銷，只是有些人比其他人更加有禮貌。他感謝 Bacik 的言論，說他很高興至少有人看到這項工作的好處。

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

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