LWN: folio 改動(dòng)未能合入！
關(guān)注了就能看到更多這么棒的文章哦～
The folio pull-request pushback
By Jonathan Corbet
September 10, 2021
DeepL assisted translation
https://lwn.net/Articles/868598/
在我們上次介紹 page folio 的時(shí)候，當(dāng)時(shí)看來(lái)它有望在 5.15 合并窗口期間被合入 mainline。Matthew Wilcox 在 8 月份正式發(fā)出了一個(gè) pull request，希望能合入 mainline。雖然 folio 仍有可能被合入到 5.15 版本，但截至目前還沒(méi)有達(dá)成這個(gè)目標(biāo)，并且可能性越來(lái)越小了。我們只看到關(guān)于 folio 方案價(jià)值的長(zhǎng)長(zhǎng)的討論。
內(nèi)核中內(nèi)存管理子系統(tǒng)是以 page 為單位來(lái)管理內(nèi)存的，這個(gè)基本單位通常由硬件決定（一般是 4KB 大小）。不過(guò)這些 "base" page 非常小，內(nèi)核經(jīng)常需要以更大的單位來(lái)處理內(nèi)存。為此，它將一些在物理上連續(xù)的 page 組合成 compound page，它們都是由一個(gè) head page（指 compound page 復(fù)合頁(yè)中的第一個(gè) base page）和一些 tail page 組成的。這就導(dǎo)致了這樣一種情況：內(nèi)核代碼收到一個(gè) struct page 的指針時(shí)，如果不仔細(xì)檢查一下的話，就無(wú)法知道它在處理的是 head page 還是 tail page。
事實(shí)證明，在代碼中加上 "確保這是一個(gè) head page" 的檢查在內(nèi)核運(yùn)行時(shí)增加了一些開(kāi)銷。并且內(nèi)核中到處都在使用 struct page，也使得內(nèi)核的 API 變的有些不明確，因?yàn)楹茈y知道某個(gè)函數(shù)是否能夠處理 tail page。為了解決這個(gè)問(wèn)題，Wilcox 創(chuàng)造了 "folio" 的概念，它就跟一個(gè) struct page 很像，但可以確定的是它絕對(duì)不會(huì)是一個(gè) tail page。通過(guò)改變 kernel 內(nèi)部的函數(shù)來(lái)使用 folio 結(jié)構(gòu)，Wilcox 提升了內(nèi)核的運(yùn)行速度，并且同時(shí)讓 API 更加清晰了。這個(gè) patch set 是非常巨大的，到處都在進(jìn)行修改（intrusive），但之前似乎已經(jīng)克服了大多數(shù)阻礙，做好進(jìn)入 mainline kernel 的準(zhǔn)備了。
Objections
內(nèi)存管理開(kāi)發(fā)人員 Johannes Weiner 很快地回復(fù)了這個(gè) pull request，他對(duì) folio 這個(gè)概念表示 "strong reservations"。在后續(xù)討論中，他把自己的反對(duì)意見(jiàn)用多種方式講述了出來(lái)，但似乎都?xì)w結(jié)為一個(gè)核心問(wèn)題：folio 只是一個(gè)物理上連續(xù) page 的集合，這將使它難以處理內(nèi)存管理所面臨的一些挑戰(zhàn)。
首先，folio 的設(shè)計(jì)泄露了太多內(nèi)存管理方面的內(nèi)部信息給其他那些使用了 folio 結(jié)構(gòu)的子系統(tǒng)，尤其是在文件系統(tǒng)子系統(tǒng)中更是如此。當(dāng)然，目前使用 page 結(jié)構(gòu)的 API 也有同樣的問(wèn)題，但他說(shuō)，大規(guī)模的 API 變動(dòng)正好是解決這個(gè)問(wèn)題的時(shí)機(jī)。因此，Weiner 多次要求創(chuàng)建一個(gè)更抽象的內(nèi)存描述方式，用來(lái)供內(nèi)核的更高層次的模塊使用。這種抽象可以隱藏很多細(xì)節(jié)，并且 folio 現(xiàn)有的物理連續(xù)、2次方 size 內(nèi)存塊的這些假設(shè)條件也可以被消除了。
他繼續(xù)說(shuō)道，物理連續(xù)的這個(gè)前提條件是一個(gè)嚴(yán)重問(wèn)題，因?yàn)閮?nèi)存管理子系統(tǒng)從來(lái)都不擅長(zhǎng)分配較大的、連續(xù)的內(nèi)存塊。在某些場(chǎng)景中，系統(tǒng)中大多數(shù)內(nèi)存都碎片化了，找不到更大的連續(xù)內(nèi)存塊了。像 page compaction 這類技術(shù)可以在一定程度上有所幫助，但它的代碼就是帶來(lái)更高的分配延遲。他說(shuō)：“事實(shí)上我們?cè)谶@方面已經(jīng)宣告失敗了。”在不解決分配這些大塊連續(xù)區(qū)域的情況下，光采用 folio 來(lái)表示更大的內(nèi)存連續(xù)區(qū)域就是沒(méi)有意義的。
他說(shuō)的另一個(gè)問(wèn)題是 folio 的概念可能會(huì)使今后改動(dòng)內(nèi)存管理子系統(tǒng)來(lái)使用更大的 base page size 變得更加困難。這種改動(dòng)會(huì)使系統(tǒng)在許多方面更加有效率，比如減少浪費(fèi)在 struct page 上的內(nèi)存，以及減少用于處理這些結(jié)構(gòu)的 CPU 時(shí)間。但是，有一個(gè)問(wèn)題導(dǎo)致內(nèi)核多年來(lái)一直沒(méi)有增加 base-page size：internal fragmentation（內(nèi)部碎片化）。
當(dāng)一個(gè)文件的內(nèi)容（或其一部分）被存儲(chǔ)在 page cache 中時(shí)，就需要一定數(shù)量的完整 page。類似 Unix 這樣的系統(tǒng)有很多小文件，但即使是一個(gè)幾個(gè)字符的文件也會(huì)在 page cache 中占據(jù)一個(gè)完整的 page。該 page 中文件末尾的內(nèi)存全都被直接浪費(fèi)了。增加 base page 的大小必然也會(huì)導(dǎo)致因這種內(nèi)部碎片而損失的內(nèi)存數(shù)量變得更多。在以前的一個(gè)討論中，Al Viro 做了一個(gè)快速計(jì)算，說(shuō)明在更大的 page size 下要保持內(nèi)核源代碼都在內(nèi)存里的話需要多少內(nèi)存。例如，64KB 的大小將使要用到的內(nèi)存 size 翻兩番。這個(gè)代價(jià)不算小了。
出于這個(gè)原因，Weiner 認(rèn)為，即使內(nèi)存管理子系統(tǒng)后續(xù)轉(zhuǎn)向更大的 base-page size，內(nèi)核也需要能夠以小的單位（例如現(xiàn)有的 4KB 大小）來(lái)進(jìn)行 file caching。換句話說(shuō)，page cache 需要能夠使用內(nèi)存中比 page 更小的單位來(lái)進(jìn)行工作。因此這里如果能使用新的內(nèi)存抽象的話可能會(huì)促進(jìn)這一點(diǎn)。而目前的 folio 概念則由于與底層 page 牢牢地聯(lián)系在一起，因此無(wú)法有所幫助。
Wilcox 對(duì)這個(gè)反對(duì)意見(jiàn)的回答似乎是說(shuō)，使用不同于 allocation size 的單位來(lái)管理內(nèi)存的話并沒(méi)有什么好處。因此，在內(nèi)存管理子系統(tǒng)中使用較大單位頁(yè)面的方法就是分配 compound page，并用 folio 來(lái)代表之。如果內(nèi)核中的所有內(nèi)容都使用較大的 page，內(nèi)存碎片就會(huì)減少，這些 page 也就會(huì)更容易分配出來(lái)。對(duì)于需要較小 page size 的場(chǎng)景，例如小文件的 page-cache entry 項(xiàng)，就可以直接使用 base page。通過(guò)仔細(xì)進(jìn)行分配，就可以讓這些單獨(dú)的 page 可以 pack 起來(lái)，進(jìn)一步避免了碎片化。
但是，Weiner 不同意這種方法，他認(rèn)為這把避免碎片的責(zé)任歸結(jié)給了錯(cuò)誤的地方。內(nèi)核的內(nèi)存分配有兩個(gè)層次：page allocator（這里處理單位是完整 page，也就是 folio 相關(guān)的地方）和 slab allocator（通常用來(lái)處理較小單位的內(nèi)存分配）。它們優(yōu)勢(shì)不同：
page allocator 擅長(zhǎng)分配統(tǒng)一的（uniform）、較大的內(nèi)存區(qū)域。slab allocator 擅長(zhǎng)將這些區(qū)域細(xì)分為更小的對(duì)象，做好整齊的 pack 和 group 管理工作來(lái)方便后續(xù)回收成連續(xù)內(nèi)存，同時(shí)向用戶空間和內(nèi)核空間的開(kāi)發(fā)者提供了每種內(nèi)存使用情況以及內(nèi)部碎片的詳細(xì)劃分。
據(jù) Weiner 說(shuō)，Wilcox 的方法讓 page allocator 來(lái)處理目前在 slab allocator 中已經(jīng)很好地解決了的問(wèn)題。"如果這就是你希望 folio 后續(xù)做的事情，那么很抱歉，我只能回復(fù) NAK"。
The real problem with folios
當(dāng)然，是否合并 folio，最終決定是由 Linus Torvalds 決定的。在討論的早期，他對(duì) API 的改進(jìn)給予了肯定，但也指出，這組 patch set 確實(shí)給內(nèi)存管理子系統(tǒng)帶來(lái)了大量干擾。他總結(jié)說(shuō) "所以我并不討厭這些 patch。我認(rèn)為它們很聰明，很可能是值得的，但我也肯定是不喜歡它們的。"
然而，他也指出，他對(duì) "folio" 這個(gè)名字并不是很滿意，這就又來(lái)到了內(nèi)核社區(qū)討論中一個(gè)經(jīng)常出現(xiàn)的規(guī)律：當(dāng)技術(shù)問(wèn)題討論很深入并難以解決的時(shí)候，一定會(huì)開(kāi)始對(duì) name 進(jìn)行擴(kuò)展辯論了。所以 David Howells 建議用 "sheaf" 或 "ream"。Torvalds 則傾向于更直接的描述性的東西，比如 "head_page"。Ted Ts'o 認(rèn)為 "mempages" 也可以，或者是 "pageset"。Nicholas Piggin 贊成 "cluster" 或 "superpage"。在討論之后，Vlastimil Babka 總結(jié)下來(lái)唯一合適的名字是 "pageshed"。
Wilcox 已經(jīng)說(shuō)得很清楚了，他并不關(guān)心這個(gè)名字是什么，只要能把代碼合入進(jìn)去，他幾乎可以接受任何名字。他重做了 pull request，把所有地方都重命名為 "pageset"，就證明了這一點(diǎn)。不出意料，這個(gè)分支討論并沒(méi)有得出什么真正的結(jié)論。
8 月底的時(shí)候，Howells 發(fā)文請(qǐng)求盡快解決這個(gè)問(wèn)題，因?yàn)檫€有很多其他有待解決的內(nèi)存管理工作，它們要么依賴于 folio patch，要么與之沖突。他問(wèn)道：
是否有可能按原樣直接接受 folios patch set 并接受這個(gè)名字，或者只接受 Willy 的重命名之后的版本（盡管它還沒(méi)有經(jīng)過(guò) linux-next 的驗(yàn)證）？還是說(shuō)這個(gè)方法有著根本性的缺陷，需要重做？
David Hildenbrand 補(bǔ)充說(shuō)，他希望看到 folios 能以任何方式從 linux-next 中移出去，越早越好。
Now what?
現(xiàn)在看來(lái)對(duì)話已經(jīng)結(jié)束了。5.15 合并窗口已經(jīng)接近尾聲，而 Folio patch 還沒(méi)有被合入。這意味著，folio patch set 最起碼也得再等待一個(gè)開(kāi)發(fā)周期了。Torvalds 有時(shí)候會(huì)將有爭(zhēng)議的 patch 保留到（甚至超過(guò)）合并窗口的結(jié)束時(shí)間點(diǎn)，那時(shí)會(huì)有更多的時(shí)間來(lái)考慮。因此，即使是合并窗口關(guān)閉了，也不意味著他已經(jīng)作出了決定。
最后結(jié)果還沒(méi)有出現(xiàn)，但無(wú)論如何很明顯的是，在內(nèi)存管理子系統(tǒng)中還有很多工作要做。很多需要進(jìn)行的改動(dòng)還沒(méi)有被設(shè)計(jì)出來(lái)，更不用說(shuō)編寫代碼和調(diào)試了。這為 Wilcox 的最后一個(gè)論點(diǎn)增加了一些支持。"Folio patch 現(xiàn)在已經(jīng)是個(gè)現(xiàn)成版本了"。或者，正如 Babka 問(wèn)到的："我們是否應(yīng)該什么都不做，一直到有人真正把這個(gè)假設(shè)中的未來(lái)變成真實(shí)代碼，然后我們?cè)倏此欠裼行В? 如果 folio 的代碼被拋棄了，那么基于它進(jìn)行的對(duì)內(nèi)存管理內(nèi)部進(jìn)行的改進(jìn)工作將不得不從頭開(kāi)始，而目前還看不出有什么人準(zhǔn)備好了要接受這一挑戰(zhàn)。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長(zhǎng)按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開(kāi)源社區(qū)的各種新近言論～