LWN：關(guān)于readahead的討論！

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

A discussion on readahead

By Jake Edge
June 15, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/897786/

Readahead 是一種 I/O 優(yōu)化，讓系統(tǒng)讀取的數(shù)據(jù)要比應(yīng)用程序所要求的更多，因?yàn)橄嘈胚@些額外的數(shù)據(jù)很快會(huì)被用上。在 2022 年 Linux 存儲(chǔ)、文件系統(tǒng)、內(nèi)存管理和 BPF 峰會(huì)（LSFMM）上，Matthew Wilcox 在 Steve French 和 David Howells 的協(xié)助下，主持了一次討論 Readahead 的會(huì)議，特別是與網(wǎng)絡(luò)文件系統(tǒng)有關(guān)的內(nèi)容。底層存儲(chǔ)設(shè)備的 latency 需要被考慮到預(yù)先多讀取多少數(shù)據(jù)的計(jì)算過(guò)程中，但如何做到這一點(diǎn)，尚未完全確定。

Wilcox 首先介紹了一下 readahead。如果用戶空間正在一個(gè)字節(jié)一個(gè)字節(jié)地讀取一個(gè)文件，那么 Linux 實(shí)際上并不會(huì)這么做；相反，它發(fā)出更大塊（bigger chunk）的讀取，比如說(shuō)每筆 64KB，這些數(shù)據(jù)被存儲(chǔ)在 page cache 里。從對(duì)存儲(chǔ)設(shè)備發(fā)起一個(gè) page 的 read，一直到它真的出現(xiàn)在 page cache 中，是有一定的 latency 的；這個(gè)延遲在 Linux 支持的各種存儲(chǔ)類型中各不相同。同樣是網(wǎng)絡(luò)存儲(chǔ)，可以是本地存儲(chǔ)在千兆以太網(wǎng)上的數(shù)據(jù)，也可以是存儲(chǔ)在地球另一端的明顯較慢的鏈接上的數(shù)據(jù)。同樣，對(duì)于本地存儲(chǔ)來(lái)說(shuō)，既可能是每秒 5GB 的 NVMe 固態(tài)硬盤(pán)，也可能是一些 "在貿(mào)易展上從供應(yīng)商處獲得的蹩腳的 U 盤(pán)"。這里有 "很多不同情況需要處理"。

[Matthew Wilcox]

根據(jù)他的經(jīng)驗(yàn)，block-layer 開(kāi)發(fā)人員傾向于使用 direct I/O 來(lái)進(jìn)行所有測(cè)試；他們認(rèn)為 "page cache 很討厭"，所以他們?cè)跍y(cè)試中避免使用它。James Bottomley 說(shuō)，他們經(jīng)常需要在測(cè)試中排除 page cache 的影響，以消除他們控制之外的那些變量。Wilcox 說(shuō)，這其實(shí)不太好，因?yàn)橛脩羲吹降男阅鼙憩F(xiàn)，是包括了 page cache 在內(nèi)的情況；如果能在用戶之前就發(fā)現(xiàn)那些由于有太多的或太少的 readahead 導(dǎo)致性能變差的問(wèn)題，那就再好不過(guò)了。

他說(shuō)，他有一個(gè) KernelNewbies 的 wiki 頁(yè)面，正在收集記錄他對(duì) readahead 和 page cache 的整體的想法。page cache "在某些方面很厲害，在其他方面則很糟糕"，但如果能解決它的問(wèn)題就好了。安卓開(kāi)發(fā)者遇到了 readahead 的問(wèn)題，但 "他們以最糟糕的方式解決了這個(gè)問(wèn)題"。他介紹說(shuō)，他們改變了 readahead 的設(shè)置，將其從 256KB 改為了幾百兆，以便能從應(yīng)用程序的啟動(dòng)時(shí)間中減少那么 "幾分之一秒"。當(dāng)然，這也會(huì)有其他的影響；當(dāng)他們?cè)噲D向上游打 patch 時(shí)，內(nèi)存管理開(kāi)發(fā)者直接會(huì)拒絕。

Howells 建議，安卓開(kāi)發(fā)者應(yīng)該使用 fadvise()（他補(bǔ)充說(shuō)或者是 madvise()）來(lái)表示文件應(yīng)該有更積極的 readahead。但 Willcox 并不同意。"我們能不能不要再假設(shè)用戶空間知道自己在做什么？" Bottomley 說(shuō)，安卓是一個(gè)特殊的環(huán)境；它使用了一個(gè)日志結(jié)構(gòu)的文件系統(tǒng)，所以他們的這個(gè)方法可能真是合理的。Wilcox 對(duì)這一點(diǎn)表示了一些懷疑。

總的來(lái)說(shuō)，有一堆 readahead 問(wèn)題需要解決。"我想說(shuō) 'f' 那個(gè)詞了，也就是 folio，其實(shí)在其中起了一點(diǎn)作用。" 目前，使用較大的 folio 的場(chǎng)景主要是由 readahead 所引發(fā)的，readahead 數(shù)據(jù)越大，容納它的 folio 頁(yè)面就越大。這對(duì)測(cè)試是很有好處的。支持更大 folio 的文件系統(tǒng)，目前只有 XFS 這一個(gè)（盡管 AFS 和 v9fs 的 patch 正在排隊(duì)等待合入），它會(huì)分配四個(gè) page （所謂的 order-2）folio。

Wilcox 說(shuō)，F(xiàn)rench 讓他知道了 Windows 在 CIFS 上為 readahead 進(jìn)行的讀取是非常大的。French 同意這一點(diǎn)，他指出，由于預(yù)期會(huì)有網(wǎng)絡(luò)延遲，Windows 可以將 readahead 提高到 16MB，盡管這似乎降低了性能。他用了一些各種不同大小（256KB、512KB、1MB、4MB）的場(chǎng)景進(jìn)行了測(cè)試，發(fā)現(xiàn)每一種都有更好的性能，最亮眼的數(shù)據(jù)是使用 512KB 時(shí)。在 Azure 云上，該值被設(shè)置為 1MB，因?yàn)橐恍?workload 在 4MB 時(shí)會(huì)有性能下降。

他說(shuō)，根據(jù)他的測(cè)試結(jié)果，Linux CIFS 服務(wù)器的默認(rèn)值是 4MB。很明顯，任何小于 1MB 的讀取都會(huì)帶來(lái)性能問(wèn)題，除非它的網(wǎng)絡(luò)速度非常快。他所看到的問(wèn)題是如果合理地設(shè)置這個(gè)值，對(duì)它進(jìn)行調(diào)小來(lái)限流，或者適當(dāng)提高。有時(shí) page cache 其實(shí)比文件系統(tǒng)知道的信息更加多，或者有時(shí)又更加少，并且還需要考慮 network layer 的影響。他不清楚這一切該如何解決。

Wilcox 說(shuō)，有一種機(jī)制可以將這種信息從文件系統(tǒng)傳遞給虛擬文件系統(tǒng)（VFS）層和使用 BDI（struct backing_dev_info）的 page cache。他說(shuō)這就是 VFS 利用來(lái)了解底層存儲(chǔ)的性能特征的地方，目前它可能沒(méi)有所有那些最合適的信息，但這是放置這類信息的位置。

當(dāng)用戶空間正在一個(gè)字節(jié)一個(gè)字節(jié)地讀取文件時(shí)，就會(huì)發(fā)出 64KB 的讀取；一個(gè) "這個(gè) readahead 是否有用 " 的標(biāo)記被放置在了 buffer 中的 20KB 位置左右，當(dāng)達(dá)到這個(gè)標(biāo)記時(shí)，就會(huì)發(fā)出另一個(gè) 64KB 單位的讀取操作。其目的是在用戶空間使用完所剩下的 44KB 之前就完成第二次讀取，但文件系統(tǒng)不知道讀取的延遲是多少。他說(shuō)，人們可以拍腦袋說(shuō)去測(cè)量一下進(jìn)行讀取所需的時(shí)間，并將其與用戶空間的消耗率進(jìn)行比較，以更好地確定何時(shí)來(lái)安排下一次 read，但這并沒(méi)有實(shí)現(xiàn)出來(lái)。

第二個(gè) 64KB 的讀取操作，就會(huì)把 mark 標(biāo)記放在 buffer 開(kāi)頭；當(dāng)達(dá)到這個(gè) mark 時(shí)，它決定增加 readahead buffer 并再讀取 128KB。它還會(huì)再增加一次（也就是到 256KB），但不會(huì)再進(jìn)一步了，盡管它可能其實(shí)應(yīng)該繼續(xù)增加。256KB 的限制已經(jīng)存在了 20 年，"在這段時(shí)間里，I/O 幾乎沒(méi)有任何變化"，Wilcox 講了一句反話。目前距離當(dāng)初增加這個(gè)限制的時(shí)候已經(jīng)過(guò)去了很多年了。Josef Bacik 讀了 Jan Kara 的聊天區(qū)評(píng)論，其中說(shuō) SUSE 多年來(lái)一直在使用 512KB 的限制。考慮到這個(gè)情況，Wilcox 認(rèn)為應(yīng)該立即將最大限值改為 1MB。

但是，與其直接增加讀取的 size，Wilcox 更愿意發(fā)出多個(gè) 256KB 的緊挨著的 read 操作，因?yàn)檫@將有助于 page cache 來(lái)跟蹤前面所讀取的數(shù)據(jù)是否真的被使用了。French 說(shuō)，這對(duì) CIFS 來(lái)說(shuō)是比較友好的，因?yàn)槎鄠€(gè)較小的 read 在性能上表現(xiàn)更好。Jeff Layton 通過(guò) Zoom 插進(jìn)來(lái)說(shuō)，他認(rèn)為單個(gè)較大的 read 對(duì) NFS 來(lái)說(shuō)更好，而聽(tīng)到較小的 read 在 CIFS 看來(lái)更加好，他表示很驚訝。

Howells 說(shuō)，哪個(gè)選項(xiàng)更好，完全取決于文件系統(tǒng)。Ted Ts'o 說(shuō)，這也將會(huì)跟底層存儲(chǔ)設(shè)備有關(guān)；在內(nèi)存受限的設(shè)備上增加 readahead 大小可能也會(huì)有問(wèn)題。不會(huì)有一個(gè) "神奇的 readahead 公式" 可以在所有情況下都適用。他建議使用 BPF 來(lái)實(shí)驗(yàn)不同的算法，這樣的話，安排一位研究生就可以很容易地嘗試各種不同的想法，看看哪種方法最有效。Wilcox 說(shuō)，他本來(lái)想反駁這個(gè)想法，但后來(lái)決定他要贊同這個(gè)主意，因?yàn)檫@樣一來(lái)就會(huì)是別人的問(wèn)題了，現(xiàn)場(chǎng)哄堂大笑。

Chuck Lever 認(rèn)為在討論中，關(guān)于 readahead 的情況被大大簡(jiǎn)化了。在一個(gè)程序每次讀取一個(gè)字節(jié)的原始例子中，沒(méi)有理由增加到 64KB 以上，因?yàn)檫@就足夠跟上程序運(yùn)行的速度了。如果請(qǐng)求太多的數(shù)據(jù)，來(lái)用實(shí)際上不會(huì)被讀取到的 page 填充了 page cache，這不是正確的做法。

還有一個(gè)問(wèn)題，例如在網(wǎng)絡(luò)文件系統(tǒng)上排隊(duì)進(jìn)行 1MB 的讀取，在讀取過(guò)程中會(huì)耽誤其他較小的 request，比如 metadata 的更新。他同意需要進(jìn)行實(shí)驗(yàn)，并認(rèn)為測(cè)試應(yīng)該要比立即增加內(nèi)核的 readahead size 要優(yōu)先完成。有必要對(duì)許多不同的 workload、文件系統(tǒng)所進(jìn)行的測(cè)試，以確定這種改動(dòng)的整體系統(tǒng)性影響是什么樣的。

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

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