OS2ATC-王榮巍.pdf

《OS2ATC-王榮巍.pdf》由會員分享，可在線閱讀，更多相關《OS2ATC-王榮巍.pdf（29頁珍藏版）》請在三個皮匠報告上搜索。

1、王榮巍阿里云研發工程師代碼大頁：針對應用代碼代碼大頁：針對應用代碼段的一種大頁優化特性段的一種大頁優化特性/目 錄/01 行業、技術背景02 實現、性能和使用03 社區04 其他想法背景 代碼大頁 社區 參考目錄05 參考 平時工作：Linux內存管理、穩定性問題；最近開始對開源CPU感興趣；工具偏好：crash、systemtap、printk；桌上足球老后衛；BIOWeixin ID：Twitter：rainpplus行業 技術背景關于大頁，可以列舉出好幾種：THP、hugetlb，全局大頁64K和16K；THP：主要分為頁表PMD或PUD映射，當前用戶態使用的大頁基本為2M PMD映射大

2、頁。Hugetlb：一種顯式的大頁使用方式，提供的大頁選擇比THP更多。全局大頁：主要指base pagesize大小大于4K，例如arm64支持16K和64K兩種粒度頁。大頁TLB是一種頁表的緩存，按類型可以分為iTLB/dTLB，按大小可以分為2M iTLB或4K iTLB或1G dTLB；iTLB/dTLB：指用于數據和指令的TLB硬件資源。某些平臺存在STLB，可緩存數據和指令的頁表。2M iTLB/4K iTLB/1G dTLB：目前我們使用的架構中用于緩存2MB大頁和4 KB頁的TLB entry資源存在兩種形式：分離或混合，以Skylake為例，每個超線程用于2 MB大頁的iTL

3、B資源僅8個，用于4K頁的TLB資源有128個。另外，arm64上是混合使用的。TLBhugetlbarm64x86THPTHPGlobal large pagesizehugetlb16K64K目前我們云上熟知的兩種架構：x86和arm，在支持的大頁可選性存在差異，主要原因還是與CPU硬件特性或者說與頁表特性有關。64K2M32M1G2M1GGlobal large pagesize差異：我們俗稱全局大頁，盡管arm64有16K和64K選擇，但是我們目前仍舊在使用4K。Hugetlb差異：在arm64上由于頁表支持CONT bit，可實現16 PTEs、16 PMDs映射支持，即64 KB和

4、32 MB大頁支持，當前僅hugetlb實現了此類大頁；差異特點描述介紹幾種典型的應用：Mysql、Postgresql和OceanBase。多進程模型，代碼段大小大約10M左右；應用iTLB-load-misses較高，大約1.41%左右；PostgreSQL數據庫Mysql是一個多線程模式的數據庫，其代碼段大小一般18M左右；THP不敏感，打開THP，大約僅有不到3%的性能提升；跨NUMA敏感，本地虛擬機32核驗證跨NUMA抖動在57%左右；Mysql數據庫多線程模型，代碼段大小打印200M280M；一般獨占單機使用，性能驗證過程中并發數要求高：128、1000、1500；THP本地驗證不

5、敏感；OceanBase數據庫共同特征：代碼段大、iTLB Miss高-THP代碼大頁方案對比：社區社區vsvs我們我們為mariadb引入large_pages_for_code選項【補丁還未接受】實現與libhugetlbfs類似，在x86上帶來的性能收益大致如下：READ_ONLY_THP_FOR_FSFB的Liu Song在19年為內核引入的一個特性，該特性主要是在khugepaged內核線程中將.text段（VMAwith VM_DENYWRITE）也考慮整合成2 MB大頁。該特性需要在開啟THP的場景下才能使用。使用libhugetlbfs將代碼段或者數據段重新映射到大頁上。使用的

6、hugetlbfs，存在的問題包括：perfperf無法查看熱點異無法查看熱點異常常、需重新編譯應用需重新編譯應用、無法使動態鏈接庫使用大頁無法使動態鏈接庫使用大頁。-THP用戶態接口：匿名頁，提供always/madvise/never三種選項，對匿名頁使用大頁進行控制；文件頁：可執行的文件頁，依賴應用主動調用madvise()系統調用使能；Linux內核已有的大頁整合機制：文件頁和匿名頁分離階段：匿名頁：在THP enabled滿足的情況下，判斷虛擬首地址是否2 MB對齊即可；文件頁：特指ELF、DSO代碼段的占用的文件頁，還需判斷pgoff是否512對齊和該文件是否有寫者；整合階段：匿名

7、頁：替換PTE映射為PMD映射，釋放掉原來的ptepgtable；文件頁：替換頁緩存pagecache中小頁為大頁；實現 性能 使用代碼大頁代碼大頁 EXEC實現Load_elf_binary()：在加載時處理好ELF地址對齊的問題 DSODSO將代碼段放入到大頁，需要解決兩個問題：地址對齊問題；沒有denywrite約束 Padding代碼大頁Padding功能可控：padding功能僅個別特殊應用需要，因此需要該功能可控：hugetext_pad_threshold；安全：padding后，保證與后續的VMA不會重疊，同時不會超過文件本身大??；可靠性為了安全，并非所有應用可以通過paddi

8、ng獲取最大性能，主要原因在于代碼段塊前后未對齊；在應用的鏈接腳本中加入“.=ALIGN(0 x200000)”，保證代碼塊2MB對齊建議主要有三部分：2 MB地址對齊khugepaged掃描加速；動態庫（DSO）支持使用大頁；代碼大頁性能測試環境 機器：ARM虛擬機 32 cores 128GB；OS：Anolis 5.10內核；kpti=off nokaslr cgroup.memory=nokmem transparent_hugepage=never numa_balancing=disable 其他：主要應用綁核綁節點；代碼大頁性能：上圖TPS對比可以看出：代碼大頁的性能始終高于普通

9、的代碼頁。關于這張圖中其他的結論，還有：并發數為1時，外在的影響因素最小，此時，代碼大頁相比普通代碼頁，性能提升大約6.9%；并發數8、16基本可以保證沒有CPU的競爭，代碼大頁的性能提升大約6.5%以上；并發數32時，相比普通代碼頁，性能提升大約在11%左右；代碼大頁微架構指標優化：上圖都展示的是iTLB的數據，在測試的過程中iTLB miss和iTLB MPKI也一并記錄。如這兩圖所示：Mysql使用代碼大頁后，iTLB miss大約下降了10倍左右，數值大小從原來的1%下降到0.08%左右；在iTLB MPKI上，大約下降了6倍左右；代碼大頁性能：PostgreSQL代碼大頁相比libh

10、ugetlbfs方案，不僅僅解決了使用libhugetlbfs后無法使用perf觀察熱點問題，同時通過padding功能，代碼大頁性能提升較libhugetlbfs多2%左右。Hugetext:9%Libhugetlb:7%base代碼段大小透明大頁代碼大頁mysql22M2%57%redis1.8M5%xpostgresql12M+x7%oceanbase200M+x7%JVM類100M+8%68%注：以上主要為arm平臺測試數據。符號x可以認為該應用沒有采用該技術，或優化效果幾乎是0。收益：64K 代碼大頁 anon THP 4kArm AMD Intel代碼大頁 使用啟動參數啟動參數打開

11、：hugetext=1 or 2 or 3關閉：缺省即為關閉sysfs接口接口僅打開二進制和動態庫大頁：echo 1 /sys/kernel/mm/transparent_hugepage/hugetext_enabled僅打開可執行匿名大頁：echo 2 /sys/kernel/mm/transparent_hugepage/hugetext_enabled打開以上兩類大頁：echo 3 /sys/kernel/mm/transparent_hugepage/hugetext_enabled關閉：echo 0 /sys/kernel/mm/transparent_hugepage/huget

12、ext_enabledPadding接口接口接口路徑：/sys/kernel/mm/transparent_hugepage/hugetext_pad_thresholdecho 02097151 /sys/kernel/mm/transparent_hugepage/hugetext_pad_threshold注意事項注意事項打開、關閉并不意味著立即合并、拆散大頁，hugetext 是異步的。如果一段代碼曾經被整理成大頁，即使關閉hugetext 功能，還是會大頁映射。想確認代碼段是否大頁映射，可以通過下面的命令確認：grep FilePmdMapped/proc/$(pidof mysql

13、d)/smaps代碼大頁 附錄1數據來源：https:/ L1 code TLB2M L2 code TLB/STLBIntel Skylake8 entries1536 entries海光（AMD）64 entries1024 entriescascade lake8 entries1536 entriesarmN148 entries1280 entries代碼大頁 附錄2grep-C 10-n ELF_MAXPAGESIZE-R./SOURCES/binutils-2.35/bfd/elf64-x86-64.cbinutils、glibc 虛擬地址對齊對于arm，該值為64K，對于x86

14、，與binutils包版本有關。大致情況如下：ARM：64KX86：Binutils-2.30/2.27：2M；Binutils-2.35：4K；ELF_MAXPAGESIZE代碼大頁 附錄2binutils、glibc 虛擬地址對齊“-z max-page-size=0 x200000”EXEC：對齊VMA首地址 DSO：ld.so可以會安裝p_align值進行對齊；代碼大頁 附錄3.=ALIGN(0 x200000)修改鏈接腳本，在.text兩端加入“.=ALIGN(0 x200000)”可以徹底保證ELF文件中兩個LOAD段在文件中的偏移為2MB對齊；社區代碼大頁 mm,thp:bail

15、 out early in collapse_file for writeback page整合文件大頁的主要函數collapse_file()調用page_has_private()判斷正在寫回的頁，這種方法對于XFS中塊大小等于或大于時，無法抓到正在寫回的頁；pagesize；mm,thp:lock filemap when truncating page cache多并發打開一個存在大頁的文件會多重進入truncate pages流程，頁狀態變量異常觸發crash；mm,thp:fix incorrect unmap behavior for private pages當truncate

16、一個文件時，應該避免對該段區域的private pages操作，例如可執行文件的rp數據，避免導致應用發生段錯誤；Linux社區 elf:Properly align PT_LOAD segments針對動態鏈接庫（DSO），修復加載器ld.so映射動態鏈接庫過程中，映射首地址按照p_align值對齊；glibc社區 代碼只讀文件系統，專門用于放置lib庫；64kB、32MB代碼大頁，接近特殊場景2MB代碼大頁無法使用的問題；多種代碼大頁支持；靶向代碼大頁；其他想法 代碼大頁ECS官網文檔 龍蜥-代碼大頁在達夢數據庫上性能驗證 Efficient Address Translation for Architectures with Multiple Page Sizes參考資料感謝龍蜥Kernel SIG地址：https:/ Kernel SIG