來源: https://lwn.net/Articles/758677/
現今的系統有著大量的記憶體, 軟體對於記憶體的需求也愈來愈高, 以 4KB-page 為單位對於系統的 MMU 與 TLB 消耗了大量的 entries. 為了避免這方面系統平台的 overhead, 通常會採用 Huge-page (在 x86 上 Huge-page 為 4MB, arm64 為 2M/1G(4KB-page) or 512M(64KB-page)), 來提高系統的效能.
現今的系統有著大量的記憶體, 軟體對於記憶體的需求也愈來愈高, 以 4KB-page 為單位對於系統的 MMU 與 TLB 消耗了大量的 entries. 為了避免這方面系統平台的 overhead, 通常會採用 Huge-page (在 x86 上 Huge-page 為 4MB, arm64 為 2M/1G(4KB-page) or 512M(64KB-page)), 來提高系統的效能.
然而長久以來,
管理者都避免對 Huge-page 作 swapping 的動作, 主要在於 Huge-page swapout 在目前 Linux
kernel 的實作 — Transparent Huge Page(THP), 會將 Huge-page 切分為 4K-page 再做
swapout, 一方面以往硬碟的寫出效能不佳, 二來需要一次寫出大量的資料, 最後是 swapin 後是以 4KB-page 的方式回復.
隨著非揮發性記憶體在軟硬體上的進展, 改變了相關的生態, 讓 swapping 這件事情再次地變得有趣. 而 THP 也從 2016 年開始帶來了相關的變革, 這些變動來大幅地增進了效能:
1. Linux 4.13 中 THP 延遲了 Huge-page 的拆分動作, 直到 swap entries 被配置之後, kernel 才會做拆分. (因此在 DRAM 中有短暫的時間消耗了 Page-Table Entries)
2. 緊接著在 Linux 4.14 中再次將拆分的動作延遲到寫入 swap device 之後, (因此在 DRAM 中都保持著 Huge-page)
3. 目前已經實作了 Huge-page 後續管理的部份, 主要在於攔截可能會讓 Huge-page 拆分的 kernel event, 並且在 swapin 時儘可能地維持住 Huge-page 的方式. 一旦系統有著餘裕提供 DRAM Huge-page, 那麼就可以享有其帶來的好處.
1. Linux 4.13 中 THP 延遲了 Huge-page 的拆分動作, 直到 swap entries 被配置之後, kernel 才會做拆分. (因此在 DRAM 中有短暫的時間消耗了 Page-Table Entries)
2. 緊接著在 Linux 4.14 中再次將拆分的動作延遲到寫入 swap device 之後, (因此在 DRAM 中都保持著 Huge-page)
3. 目前已經實作了 Huge-page 後續管理的部份, 主要在於攔截可能會讓 Huge-page 拆分的 kernel event, 並且在 swapin 時儘可能地維持住 Huge-page 的方式. 一旦系統有著餘裕提供 DRAM Huge-page, 那麼就可以享有其帶來的好處.
依照在
patch 提交時所附上的 benchmark 的數據顯示, 未修改的 kernel 僅有 4.5% 的資料最後以 huge-page 存放.
而套用 patch 後提升為 96.6%. Inter-process interrupt 降低了 96% 此外 spinlock
等待的時間自 13.9% 降為 0.1%. Swapping 的 I/O throughput 增加超過 1000%. 通常 kernel
工作者必須很努力才能取得 1% 規模的效能增益, 如此的增進幅度是罕見的.
沒有留言:
張貼留言