[轉帖]openEuler 22.03 LTS 核心基礎頁大小配置選項討論

济南小老虎發表於2024-03-31
https://gitee.com/openeuler/kernel/issues/I4HDHZ

簡介

頁表在作業系統中作為最基礎的記憶體分配結構，ARM64 支援 4K、16K、64K 不同大小的頁表。當前頁表大小隻支援靜態配置，不支援動態修改。OS 一旦選定一個頁表大小，為了相容性考慮，在該版本生命週期內，一般不會再修改。openEuler 20.03 LTS ARM64 選擇的是 64K 頁表。當前有多個使用者反饋，64K 存在相容性問題。因此重新討論後續的 22.03 LTS （5.10核心）頁表大小的選擇。

頁表SIZE的影響

相容性

jemalloc 64K 4K pagesize 的OS需要出不同的二進位制版本

redis 預設使用了jemalloc進行記憶體管理。由於jemalloc 在編譯時就決定了page size的大小，而這個page size 會由於kernel的配置而改變，因此jemalloc在某個機器上編譯，然後執行在其它機器上時可能會出現問題。

![img](openEuler 22.03 LTS 核心基礎頁大小配置選項討論.assets/20211126142433683001.png)

RHEL 9 選擇 4K pagesize 也是基於相容性考慮

Red Hat has selected a 4 KB page size of physical memory for the 64-bit
ARM architecture in Red Hat Enterprise Linux 9. This size pairs well
with the workloads and memory amounts present on the majority of
ARM-based systems. To employ large page sizes efficiently, use the
huge pages option to address a greater amount of memory or workloads
with large data sets.

Can't able to install RHEL 8.3 ARM 64 on MAC with Apple Silicon (M1) Processor

Latest response November 17 2021 at 4:24 PM

Can't able to install RHEL 8.3 ARM 64 on MAC with Apple Silicon (M1) Processor

Based on one of the other forum discussions, I came to know that the RHEL assumes
64kb CPU page size whereas M1 MAC is compatible only with 4kb or 16kb size. Is it true?
I tried to install on various hypervisors - Parallels, QEMU and all ended up in same
issue. It is not even able to boot the DVD.

Any workaround to install RHEL on M1 MAC?

其他相容性問題

1.某些硬體廠商, TCP offload網路卡, 驅動和微碼裡邊將page_size寫死為4096; 如果不是4K頁表, 執行會出錯;
2.使用者態軟體, 相容多個OS的時候, 如果頁表不同, 會導致mmap相關係統呼叫不相容;

效能

MySQL 資料庫

資料測試效能有所波動，總體範圍64K頁表會比4K頁表效能有所提升，提升範圍在5%-25%之間，平均效能只讀提升約12%左右。效能指標以tps為標準進行測試。

支援的地址範圍

ARM64 虛擬記憶體管理支援4K頁搭配3級頁表/4級頁表，64K頁搭配2級頁表/4級頁表

52BIT VA/PA 依賴 64K 頁表；
4K 頁表最大支援到 48BIT VA/PA.

https://www.kernel.org/doc/html/v5.8/arm64/memory.html

AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)
AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)

記憶體消耗

透過free指令分別對4K/64K進行分析，空載狀態下4K頁表的available空間相較64K頁表大將近1G如下：
Free –m 指令下12G虛擬機器空載
4K:
              total        used        free      shared  buff/cache   available
Mem:          11469     476       10566           8         426       10805
Swap:          4095           0        4095

64K:
              total        used        free      shared  buff/cache   available
Mem:          11648      534       10690          20         423        9989
Swap:             0           0           0

作業系統實體記憶體管理開銷

1.如果使用64K頁表, 會導致核心記憶體底噪增加;
2.如果使用者態軟體使用LWT協程, 協程的堆疊基於page_fault動態增長, 則64K頁表會浪費大量記憶體;

作業系統實體記憶體開銷包含管理頁面數開銷，cgroup管理開銷，pagetables開銷，taskstruct管理開銷等，可以明確算出來的開銷，這部分開銷64K頁相比4K大約可以節省2880(3072)M記憶體.

單板記憶體總量（GiB）128128
程序數 4096 4096
Pages管理開銷 2,048.0 128.0
記憶體cgroup管理開銷 1,024.0 64
pagetables 256 256
管理程序開銷 75.4 75.4
kdump預留記憶體 256.0 256.0

對記憶體大頁的影響

記憶體大頁的原理是基於現有頁表層級，減少一級頁表來支援更大的頁面，從而提升效能。對於4k頁表，使用8位表示頁表基地址，這樣記憶體大頁可以擴充套件到2M，1G，如果使用64K頁 3級頁表，使用13位表示頁表基地址，這樣對應的記憶體頁面大小分別擴充套件到512M(64K2^13),4G(512M2^13)

業界其他OS的選擇

OS頁表選擇VA/PA BITSNR_CPUSNODES_SHIFT（NODES)
RHEL/CentOS 7 Series 64K 48 4096 2 (4)
RHEL/CentOS 8 Series 64K 48/52 4096 3 (8)
RHEL/CentOS 9 Series 4K 48 4096 6 (64)
SLE12-SP1-ARM 64K 42 128 2 (4)
SLE12-SP2 4K 48 128 2 (4)
SLE12-SP3/SP4 4K 48 256 2 (4)
SLE15-SP1 4K 48 480 2 (4)
SLE15-SP2/SP3/SP4 4K 48 768 6 (64)
SLE15-SP4 (64K) 64K 52 768 6 (64)
ubuntu 20.04 4K

決策訴求

決策點1：openEuler 22.03 LTS 是否預設採用 4K 頁表

決策點2：openEuler 22.03 LTS 是否單獨出64K頁表的 kernel 包

kernel sig 交流群討論

@Jason: 64K，不管是伺服器還是高效能嵌入式控制器，未來都需要更大的頁大小。之前做過一種磁碟陣列的控制器，發現 Pagesize 改成64K，效能提升很大。對 IOT 裝置，4K 很好。但是對於高效能裝置，比如企業儲存系統或多CPU的HPC，那肯定是64K無敵。

@驢肉火燒: 64K 會有相容性問題，需要大頁就自己使用大頁即可。

@李俊良: 社群確實還是得照顧生態。

@Leo: 贊同，不建議預設 64K。

@雨輕: 在一些效能測試，4K差的太遠了，建議64K

@楊洋: 64K 也會增加記憶體總佔用量。

@康師傅: 有些程式在64K記憶體頁下無法執行。有些程式使用系統的 PAGESIZE 引數，然後按照4k進行記憶體對齊操作，如果變成64K，這個計算就會出錯，導致程式執行錯誤。有太多應用程式都是按照4k記憶體頁來編寫程式碼的。全部改掉不太現實。

@Leo: 據我瞭解，arm64 處理器soc在硬體設計時，片內外設控制器的暫存器地址分部好多都是做的4k對齊，還有一些pci裝置 BAR空間可能會按4k對齊，如果pagesize是64K的話，可能使用者態驅動用不了。當然64K效率更高，但是犧牲了記憶體資源，力度越大，碎片越多吧。至少4K跑著都沒問題，然後需要用大塊記憶體時，看一看用大頁。或者自己重新編譯64k 的核心。

@jiao: 有的應用的 4k，64k 執行不起來。沒有統計過4k 64k 場景佔比。

@肖磊: 64K 的話，預設 arm 的本上起虛擬機器跑尤拉都有問題，還是4k對開發者友好一些。

@Coly: pagesize 4k 挺好。咱們的配置可以看一下 redhat 和 suse 的arm配置，儘量和他們一樣。再這樣也有利於對一些重要的企業軟體做相容性認證。SAP Hana 用的是透明大頁，核心還是4K，使用者態透明大頁。（RHEL 9 使用的是4K）那看來還是4K好。

@王丹: 4K 對應用、驅動 友好，對 TLB 不友好。特別的，對 intel 家的一些網路卡晶片來說（如E810），非4K page 會導致 RDMA 功能跑不起來。有辦法測試出更多級差別及TLB miss 帶來的效能損失嗎？除了這兩點，其他角度看 4K 更好。

@陰進濤: 還是選 4k 好一些。

@王丹: 看起來各方面都遇到過不少64K相關的問題，想軟體生態妥協，遇到效能問題請用 HugePages。 如此的話，是應該選擇 4K。

相關文章