聊進程地址空間這件事我一般不喜歡從教科書上那張代碼段、數(shù)據(jù)段、堆、棧的示意圖講起因為那張圖太干凈了,干凈到看不出真實系統(tǒng)里那些別扭的取舍。我更愿意先拋一個問題如果一個進程拿到的地址就是物理內(nèi)存里的真實地址,它敢不敢隨便用答案顯然是不敢。它不僅不敢隨便用,連自己該用哪一塊都沒法事先知道——因為同一時刻可能有幾十上百個進程在跑,誰先來誰后到、誰大誰小,全都不確定。進程地址空間、虛擬地址、頁表、寫時拷貝這一整套機制,本質(zhì)上就是給這個混亂場面建立秩序的工具。搞嵌入式的同學可能覺得這些東西離自己很遠,但只要你的代碼跑在帶 MMU 的芯片上、只要你用過fork、只要你的程序莫名其妙漲過內(nèi)存,這套機制就在你腳下。這篇內(nèi)容我打算把地址空間為什么存在頁表怎么把映射做成硬件能查的表寫時拷貝到底省了什么、又偷偷付出了什么這幾件事掰開講,再配三個能直接跑的驗證實驗,讓你不用只靠想象去理解它們。1. 先把地址這件事說透虛擬地址空間到底解決了什么問題1.1 從一段裸機代碼說起物理地址直編的四個坑在單片機上寫程序的時候,我們經(jīng)常是這么干的*(volatile uint32_t *)0x40001000 1;直接把某個外設寄存器地址寫進代碼里。這種寫法在單任務、無 MMU 的環(huán)境下毫無問題,因為整個系統(tǒng)只有一份地址空間,誰也不會跟你搶。但一旦把場景換成多任務操作系統(tǒng),這種物理地址直編的思路立刻會撞上四面墻。第一面墻是隔離。進程 A 在地址 0x1000 處存了個關鍵結構體,進程 B 因為指針算錯也往 0x1000 寫,結果 A 的數(shù)據(jù)被悄悄改掉,而且這種 bug 極難定位——A 崩潰的時候 B 早就跑完了。第二面墻是重定位。編譯器在編譯期根本不知道自己的代碼會被加載到物理內(nèi)存的哪個位置,如果按固定地址生成跳轉(zhuǎn)指令,加載位置一變?nèi)P皆輸。第三面墻是稀疏使用。一個進程可能只用了 1MB 內(nèi)存,但它需要一段連續(xù)的大地址區(qū)間來放棧、放堆,如果按物理地址分配,就得真的預留那么多連續(xù)物理頁,浪費得離譜。第四面墻是共享與回收。多個進程跑同一個可執(zhí)行文件,按理說代碼段應該只有一份,但物理地址直編的模型下沒法表達兩個進程的某段地址指向同一塊物理內(nèi)存這個概念。虛擬地址空間就是把這幾面墻一次性推倒的方案。每個進程都擁有一份獨立的、從 0 開始一直延伸到某個上限的地址空間,進程里所有指針、所有跳轉(zhuǎn)、所有malloc返回的值,都是這個空間里的虛擬地址。真實物理內(nèi)存在哪里、有多少、是不是連續(xù)的,進程完全不需要知道,也完全無法知道。1.2 虛擬地址空間的本質(zhì)一層可編程的映射我習慣把虛擬地址空間理解成一張可編程的對照表。表的左邊是虛擬頁號,右邊是物理頁號,中間還掛著幾個權限位。CPU 每次訪存,MMU 拿虛擬地址去查這張表,查到了就換成物理地址去訪問內(nèi)存,查不到或者權限不對就拋異常。這張表由操作系統(tǒng)維護,進程自己改不了,這就是隔離的物理基礎。這層抽象帶來的好處是連鎖反應式的。因為映射關系是可編程的,操作系統(tǒng)可以在進程啟動時把可執(zhí)行文件的代碼段映射到任意物理頁上,于是位置無關加載變成了默認行為。因為映射是頁粒度的,一個進程的地址空間里可以有大片沒有映射的空洞,訪問到就觸發(fā)缺頁異常,操作系統(tǒng)再決定是分配一頁、還是從磁盤讀回來、還是干脆殺掉進程,于是按需分配成為可能。因為映射表里可以記錄這一頁是只讀的,多個進程可以共享同一塊物理內(nèi)存,誰想寫就觸發(fā)異常,內(nèi)核再給誰單獨復制一份,于是共享庫和寫時拷貝順理成章。我特別想強調(diào)一點虛擬地址空間這套東西之所以能成立,是因為它把進程看到的世界和真實的世界徹底解耦了。進程以為自己獨占了一整塊連續(xù)的、從 0 開始的內(nèi)存;內(nèi)核知道這全是假的,物理頁散落在各處,隨時可以被換出、被遷移、被共享。這種謊言不是欺騙,而是一種極其成功的接口設計——它讓上層程序員可以用最簡單的心智模型寫代碼,把復雜性全部壓到內(nèi)核和硬件那一層。1.3 進程地址空間布局一張圖背后藏著的信息在 64 位 Linux 上,一個典型進程的虛擬地址空間大致長這樣區(qū)域內(nèi)容增長方向典型說明代碼段 text機器指令固定通常只讀、可執(zhí)行,多進程共享數(shù)據(jù)段 data已初始化全局/靜態(tài)變量固定可讀寫,私有BSS未初始化全局/靜態(tài)變量固定不占文件空間,加載時清零堆 heapmalloc小對象向高地址由brk擴展,連續(xù)映射區(qū) mmap大塊malloc、共享庫、文件映射向低地址從高地址往下長,靈活棧 stack局部變量、調(diào)用幀向低地址主線程默認 8MBvdso/vvar內(nèi)核提供的高頻調(diào)用實現(xiàn)固定免去系統(tǒng)調(diào)用開銷這張表里有兩個細節(jié)是很多人忽略的。第一,堆和映射區(qū)是相向生長的。malloc小內(nèi)存走brk把堆頂往高推,大內(nèi)存(默認閾值 128KB 左右,由M_MMAP_THRESHOLD控制)走mmap在高地址區(qū)找一塊空地,兩者中間留出巨大空隙,誰先撞上誰觸發(fā)擴展或失敗。第二,代碼段和共享庫是真正共享物理頁的,不是各自復制一份。你在 /proc 的 smaps 里看到共享庫的Shared_Clean很大,而Private_Dirty很小,就是這個原因。還有一個容易誤解的點64 位下用戶態(tài)可用的虛擬地址并不是完整的 64 位,而是 48 位(4 級頁表)或者 57 位(5 級頁表,需要顯式開啟)。低半?yún)^(qū)屬于用戶進程,高半?yún)^(qū)留給內(nèi)核,中間是一條不可跨越的鴻溝。所以你在 64 位程序里打印指針,看到的基本都是0x0000_7fxx_xxxx_xxxx這樣開頭的值,不會是0xffff_...。2. 頁表把映射做成硬件可查表2.1 為什么是頁而不是字節(jié)有人會問既然要做映射,為什么不做成字節(jié)粒度的映射表,一字節(jié)虛擬地址對應一字節(jié)物理地址原因很直接——這張表會大到無法存儲。假設一個進程有 4GB 虛擬空間,字節(jié)粒度映射表每項至少 8 字節(jié),那光映射表就要 32GB,比地址空間本身還大,荒謬。頁粒度是一個甜點。以 4KB 頁為例,4GB 地址空間需要 100 萬個表項,每項 8 字節(jié),總共 8MB。勉強能接受,但還不夠好——因為絕大多數(shù)進程根本用不滿 4GB,為空洞付 8MB 代價太虧。這就逼出了下一層的優(yōu)化分級。而如果選更大的頁,比如 2MB,表項數(shù)量降到 2048 個,表只有 16KB,但內(nèi)部碎片會變嚴重——一個進程只用了 1 字節(jié)也得占 2MB。4KB 是歷史上軟硬件妥協(xié)出來的結果,和磁盤扇區(qū)、內(nèi)存顆粒的行緩沖都有關系,至今仍是絕大多數(shù)體系結構的默認頁大小。這里有個數(shù)值得記住4KB 2^12,所以虛擬地址的低 12 位是頁內(nèi)偏移,永遠不會被翻譯,原樣透傳到物理地址的低 12 位。這個設計讓翻譯這件事變得極其簡單——MMU 只需要處理高位,低位直接抄過去。2.2 多級頁表用時間換空間的經(jīng)典取舍單級頁表的問題是,一張表必須連續(xù)存放,而它要覆蓋整個地址空間。48 位虛擬地址、4KB 頁,需要 2^36 個表項,每項 8 字節(jié),單張表就是 512GB。這顯然不可能。解決辦法是把這張大表切碎、分層,變成一棵樹。x86-64 的 4 級頁表是這么切的把 48 位虛擬地址拆成 5 段,[47:39] [38:30] [29:21] [20:12] [11:0],前四段各 9 位,正好每段能索引 512 個表項;最后 12 位是頁內(nèi)偏移。每張頁表頁正好 4KB,裝 512 個 8 字節(jié)表項,大小嚴絲合縫。層級索引位單表容量單表覆蓋范圍表項指向PML447:39512 項512 × 512GB 256TBPDPT 頁PDPT38:30512 項512 × 1GB 512GBPD 頁PD29:21512 項512 × 2MB 1GBPT 頁PT20:12512 項512 × 4KB 2MB物理頁這套設計的精妙之處在于不為空洞付錢。一個進程如果只在某個 2MB 區(qū)間里用了幾頁,那么 PML4、PDPT、PD 各需要一張表(各 4KB),PT 也需要一張(4KB),總共 16KB 頁表就能支撐起這幾頁的映射;而地址空間里其他廣袤的空白區(qū)域,對應的頁表頁根本不存在,頂級表項直接標記為未映射。這就是分級頁表用空間效率換來的代價——查表要爬樹。爬樹的成本是可以量化的。一次 TLB 未命中,MMU 要依次讀 PML4、PDPT、PD、PT 四張表,每讀一張都是一次內(nèi)存訪問(這些表都在內(nèi)存里,只是被硬件緩存加速),最后才拿到物理頁號,再去讀真正的數(shù)據(jù)。最壞情況是 5 次內(nèi)存訪問才能拿到一個字節(jié)。如果每次都這樣,程序會慢到?jīng)]法用。所以 CPU 里專門放了一個 TLB(Translation Lookaside Buffer),緩存最近用過的虛擬頁號到物理頁號的對應關系。TLB 命中的時候翻譯幾乎是零成本的,這也是為什么局部性好的程序跑得快——不只是緩存命中率高,頁表翻譯的緩存命中率也高。2.3 頁表項里到底存了什么一張頁表項是 8 字節(jié),但物理頁號只占其中一部分,剩下的位全是標志位。理解這些位,才能理解內(nèi)核的很多行為。以 x86-64 的 4KB 頁表項為例位名稱含義實際影響0P存在位為 0 表示該頁不在內(nèi)存,訪問觸發(fā)缺頁1R/W讀寫位為 0 時寫操作觸發(fā)保護異常2U/S用戶/內(nèi)核位為 0 時用戶態(tài)訪問觸發(fā)異常3PWT寫通影響緩存策略,普通應用很少關心4PCD禁止緩存用于映射設備內(nèi)存5A已訪問硬件置位,內(nèi)核據(jù)此判斷頁的活躍度6D已臟寫過的頁,換出時需要回寫7PS大頁標志在 PD 層置位表示 2MB 大頁8G全局TLB 不隨 CR3 切換刷新12-51物理頁號高位地址指向?qū)嶋H物理頁63XD禁止執(zhí)行置位后該頁不可執(zhí)行,NX 保護的來源我經(jīng)常拿R/W位來講寫時拷貝,因為它是整套機制里最四兩撥千斤的一個位。內(nèi)核在fork之后把所有可寫的私有頁在父子兩個進程的頁表里都標成只讀,數(shù)據(jù)本身一個字節(jié)都沒動;等到某一方真的去寫,硬件發(fā)現(xiàn)R/W0,拋出保護異常,內(nèi)核在異常處理里再決定是復制一頁還是恢復可寫。整個復制動作被推遲到了真正需要的那一刻,而且只復制真正被寫的那一頁。A位和D位也有講究。內(nèi)核的頁面回收算法需要知道哪些頁最近被訪問過,硬件每次訪問都會把A置 1,內(nèi)核掃描時讀一下、清一下,就能近似判斷出頁的熱度。這不是精確統(tǒng)計,但足夠用,而且完全不占用軟件開銷。這種讓硬件順手干活的思路在體系結構里到處都是。2.4 TLB 與頁表遍歷的真實開銷很多人學完頁表會有個模糊印象查表很慢,但 TLB 救了它。這個說法沒錯,但太籠統(tǒng)。我想給幾個更具體的數(shù),便于你判斷什么時候該關心它。TLB 通常分兩級L1 dTLB 只有幾十到一百多個條目,覆蓋幾 MB 到幾百 KB;L2 TLB 稍大,幾千條,覆蓋幾 MB 到幾十 MB。也就是說,如果一個程序的工作集(活躍頁數(shù))小于 L2 TLB 的覆蓋范圍,翻譯開銷基本可以忽略;一旦工作集超過這個范圍,TLB 開始頻繁未命中,每次未命中要爬 4 級頁表,性能會掉一個臺階。這就是大頁存在的理由。2MB 大頁只需要 PD 層一個表項,不需要 PT 層,一次 TLB 表項就能覆蓋 2MB 而不是 4KB,覆蓋率提升 512 倍。數(shù)據(jù)庫、JVM 這類吃內(nèi)存大戶經(jīng)常開透明大頁,收益主要就在這里。代價是大頁內(nèi)部的碎片沒法回收,內(nèi)存緊張時反而會拖累系統(tǒng),所以很多場景又會關掉它。這是一個很典型的沒有銀彈案例。還有一個常被忽略的成本切換進程要換頁表基址。x86 上頁表基址存在 CR3 寄存器里,進程切換時內(nèi)核寫 CR3 指向新進程的 PML4,這個動作會讓 TLB 里大部分條目失效(除非用了 PCID 之類的機制給條目打標簽)。所以高頻的進程切換不僅浪費在保存寄存器上,還浪費在 TLB 冷啟動上。這也是為什么線程切換比進程切換便宜——同一地址空間,CR3 不用換。3. 寫時拷貝fork 性能的一次關鍵妥協(xié)3.1 fork 為什么要拷貝,又為什么不想拷貝fork的語義是創(chuàng)建一個和自己一模一樣的子進程,最直白的實現(xiàn)就是把父進程的所有內(nèi)存逐字節(jié)復制一份給子進程。這在小進程上沒問題,但一個占了幾個 GB 的服務進程 fork 一次,復制幾 GB 數(shù)據(jù),耗時可能到秒級,期間父進程還得停下來配合。這在早年的 Unix 上就是個大問題。寫時拷貝的思路是先別復制,讓父子共享同一份物理頁,把頁表里的寫權限全部收掉。如果父子倆從此只是讀,那就一直共享下去,零成本;如果某一方要寫,硬件拋出保護異常,內(nèi)核在異常里才真正復制那一頁,并且只復制被寫的那一頁。這樣,fork的實際開銷從復制全部數(shù)據(jù)降級成復制頁表項,通常能快一到兩個數(shù)量級。但這里有個被嚴重低估的事實頁表本身還是要復制的。fork的時候內(nèi)核要遍歷父進程的所有 VMA(虛擬內(nèi)存區(qū)域),為子進程建立同樣的 VMA 結構,然后遍歷頁表,把每一級的表頁也復制一份出來——因為父子進程的頁表必須各自獨立,否則一方改頁表項會影響到另一方。對一個映射了幾十 GB 內(nèi)存的進程來說,光是復制頁表頁就可能要幾百 MB 的內(nèi)存和相當可觀的時間。所以COW 讓 fork 變得免費是個錯誤認知,更準確的說法是COW 把 fork 的成本從數(shù)據(jù)量級降到了頁表量級。我給個量化的例子。假設一個進程映射了 8GB 匿名內(nèi)存,頁大小 4KB,那么頁表項有 200 萬個,PT 頁有 4000 個,加上各級上層表,頁表總大小約 16MB 左右。fork時這 16MB 要被復制,200 萬個 PTE 的R/W位要被清掉,這個遍歷本身就要幾十毫秒。相比之下 8GB 的數(shù)據(jù)復制要幾秒。差了將近兩個數(shù)量級,但絕對不是零。3.2 COW 的完整觸發(fā)鏈路想真正吃透 COW,得把從fork到某一頁被復制的完整鏈路走一遍。我用 Linux 的實現(xiàn)做參照,其他系統(tǒng)的結構大同小異。第一步,fork進入內(nèi)核,走copy_process。這里會創(chuàng)建新的 task 結構、新的 mm 結構(地址空間描述符),然后調(diào)用copy_mm。第二步,copy_mm判斷是否共享地址空間。如果是clone帶CLONE_VM標志(線程),直接共享 mm,什么都不復制;如果是fork,調(diào)用dup_mmap逐條復制 VMA。這一步會把父進程的每個 VMA 用vm_area_dup復制一份,掛到子進程的 mm 上,同時把父子雙方的 VMA 都標記為VM_MAYWRITE之類的共享狀態(tài),并建立反向映射結構。第三步,copy_page_range遍歷頁表。對每一個有效的 PTE,內(nèi)核把對應物理頁的引用計數(shù)加一,然后把父子雙方的 PTE 的R/W位清零,同時保留PTE_W在軟件位里的記錄(_PAGE_RW的軟件備份,不同內(nèi)核版本用不同方式記),以便將來恢復。注意,這里改的是父子兩份頁表,因為頁表已經(jīng)各自獨立了。第四步,某一方執(zhí)行寫操作。CPU 發(fā)現(xiàn)目標頁的 PTE 里R/W0,但頁是存在的,于是拋出 page fault,錯誤碼里帶上寫和保護違規(guī)兩個標志。第五步,內(nèi)核缺頁處理。do_page_fault拿到pt_regs和錯誤碼,判斷出這是寫保護導致的可恢復異常,進入handle_pte_fault分支,再走到do_wp_page。第六步,do_wp_page做決策。它先看這個物理頁當前的引用情況如果只有當前進程在用(引用計數(shù)為 1),說明另一方早就復制走了或者根本沒共享,那就直接把 PTE 改回可寫,什么都不復制,這叫reuse 優(yōu)化;如果還有別人在用,就分配一個新頁,把舊頁內(nèi)容memcpy過去,新頁掛到當前進程的 PTE 上,舊頁引用計數(shù)減一。第七步,更新 TLB。頁表改了之后,要刷新對應的 TLB 條目,否則 CPU 還會用舊的翻譯結果。這一步做漏了就會出現(xiàn)極難排查的數(shù)據(jù)不一致問題。這條鏈路里,do_wp_page的 reuse 判斷是關鍵的性能分水嶺。很多場景下父進程 fork 完就exec,子進程立刻換掉整個地址空間,父進程這邊根本不會有寫沖突;或者 fork 之后只有一方活著,另一方早就退出,頁的引用計數(shù)掉回 1,后續(xù)的寫就能直接復用。真正需要復制的情況,往往比想象中少。3.3 引用計數(shù)與頁生命周期COW 能成立,前提是內(nèi)核精確知道這一頁現(xiàn)在被幾個地方引用著。Linux 用struct page里的_refcount(總引用數(shù),包括頁表引用、page cache 引用、內(nèi)核內(nèi)部引用)和_mapcount(被多少個用戶頁表映射)兩個字段共同管理。fork時,每個被共享的可寫頁的_mapcount加一,_refcount加一。子進程退出時,它映射的每一頁都要減回去。觸發(fā) COW 復制時,新頁的計數(shù)從零開始建立,舊頁的計數(shù)減一。如果減到_mapcount為 1,意味著只剩一個映射者,再寫就可以直接復用。這套計數(shù)機制出問題時的表現(xiàn)很有迷惑性。引用計數(shù)漏加會導致頁被提前釋放,表現(xiàn)為隨機的內(nèi)存損壞或者莫名的段錯誤;引用計數(shù)多加會導致頁永遠回收不掉,表現(xiàn)為內(nèi)存持續(xù)上漲但查不到泄漏點。我見過一個案例,某開發(fā)者在驅(qū)動里手工改 PTE 實現(xiàn)共享內(nèi)存,忘了同步加_mapcount,結果系統(tǒng)跑幾小時后必然崩,查了兩天才定位到。還有一個容易忽略的點COW 和文件映射的交互。文件私有映射(MAP_PRIVATE)在被寫時也走 COW,但它多一層語義——寫完之后這頁就變成了匿名頁,不再和文件關聯(lián),后續(xù)的文件修改不會反映過來。這個行為很多人以為是 bug,其實是設計如此。3.4 COW 不是銀彈坑在哪寫時拷貝用得不當會帶來幾個典型問題,我在實際項目里都踩過。第一個坑是大頁 COW。如果開了透明大頁,一個 2MB 的大頁被 COW,復制的是整整 2MB 而不是 4KB。一個進程如果頻繁 fork 且每次都寫一點點,開了大頁之后內(nèi)存占用和復制開銷都會暴漲。這種情況要么關掉大頁,要么用madvise(MADV_NOHUGEPAGE)在特定區(qū)域禁掉。第二個坑是內(nèi)存賬算不準。父子進程共享的頁,在各自的 smaps 里都會算進 RSS,于是把父子的 RSS 加起來會遠大于實際物理占用。要準確看共享情況,得看Pss(按共享比例分攤)而不是Rss。做容量規(guī)劃的時候如果只看 RSS,會嚴重高估。第三個坑是fork 之后立刻大改。有些程序 fork 出子進程后馬上在子進程里遍歷修改一個大數(shù)組,這時候每一頁都觸發(fā)一次 COW,等于把復制成本從 fork 時刻挪到了運行時刻,總成本一點沒省,而且還多了幾百萬次缺頁異常的開銷。這種場景不如直接vfork加exec,或者用posix_spawn。第四個坑是和內(nèi)存回收打架。COW 產(chǎn)生的匿名頁在內(nèi)存緊張時會被換出,但父子共享期間頁被標成只讀,回收路徑要特殊處理。極端情況下,內(nèi)存壓力大時 COW 缺頁會因為要先回收內(nèi)存才能分配新頁,導致延遲抖動明顯。這個在延遲敏感的服務里很致命。4. 動手驗證把抽象的東西量出來4.1 環(huán)境與工具準備光看文字容易產(chǎn)生我懂了的錯覺,所以我建議你親手跑一遍下面的實驗。環(huán)境要求很簡單一臺 64 位 Linux,裝了 gcc,有 root 權限(讀 pagemap 需要),內(nèi)核版本 4.x 以上。核心工具就三個/proc/self/pagemap用來查虛擬頁對應的物理頁號;/proc/self/maps看虛擬地址區(qū)間;/proc/self/smaps看每個區(qū)間的詳細內(nèi)存賬。pagemap 的格式是一個大文件,每 8 字節(jié)對應一個虛擬頁,文件偏移 虛擬頁號 × 8。表項里 bit 63 是頁是否存在,bit 0-54 是物理頁號。注意從 4.x 某個版本開始,非特權用戶讀到的物理頁號字段會被清零,所以必須用 root 跑。4.2 實驗一同一虛擬地址在不同進程指向不同物理頁這個實驗要驗證的核心事實是fork 之后父子進程打印出來的指針值完全一樣,但通過 COW 之后它們指向的物理頁不一樣了。#define _GNU_SOURCE #include stdio.h #include stdlib.h #include unistd.h #include fcntl.h #include sys/mman.h #include sys/wait.h static unsigned long long pfn_of(void *addr) { unsigned long long entry 0; int fd open(/proc/self/pagemap, O_RDONLY); if (fd 0) { perror(open pagemap); return 0; } off_t off (off_t)(((unsigned long)addr 12) * 8); if (pread(fd, entry, sizeof(entry), off) ! sizeof(entry)) { close(fd); return 0; } close(fd); if (!(entry (1ULL 63))) /* 頁不在內(nèi)存 */ return 0; return entry ((1ULL 55) - 1); } int main(void) { size_t page (size_t)sysconf(_SC_PAGESIZE); int *p mmap(NULL, page, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (p MAP_FAILED) { perror(mmap); return 1; } *p 0x1234; printf(parent pid%-6d va%p pfn%-8llu val0x%x\n, getpid(), (void *)p, pfn_of(p), *p); pid_t pid fork(); if (pid 0) { perror(fork); return 1; } if (pid 0) { printf(child pid%-6d va%p pfn%-8llu val0x%x\n, getpid(), (void *)p, pfn_of(p), *p); *p 0x5678; /* 觸發(fā) COW */ printf(child after-write va%p pfn%-8llu val0x%x\n, (void *)p, pfn_of(p), *p); _exit(0); } waitpid(pid, NULL, 0); printf(parent after-child va%p pfn%-8llu val0x%x\n, (void *)p, pfn_of(p), *p); return 0; }編譯和運行gcc -O0 -g -o cow_demo cow_demo.c sudo ./cow_demo我用-O0是為了防止編譯器把*p的讀寫優(yōu)化掉。跑出來的結果應該長這樣(具體頁號每次不同)parent pid12001 va0x7f3a2c000000 pfn284117 val0x1234 child pid12002 va0x7f3a2c000000 pfn284117 val0x1234 child after-write va0x7f3a2c000000 pfn631842 val0x5678 parent after-child va0x7f3a2c000000 pfn284117 val0x1234三個關鍵結論全在這幾行里。虛擬地址完全一致,父子倆都以為自己用的是0x7f3a2c000000。fork 剛完成時物理頁號也一致,說明數(shù)據(jù)確實沒被復制。子進程寫完之后物理頁號變了,父進程的沒變,而且父進程讀到的值還是0x1234,說明 COW 只復制了被寫的那一頁,沒有影響另一方。這個結果和原理對得上,你才算真的理解了。這個實驗我建議你多跑幾次,把pfn_of換成查多個頁,比如一次性 mmap 1MB(256 頁),子進程只寫第 0 頁和第 100 頁,看看有多少頁的物理號變了。你會發(fā)現(xiàn)只有那兩頁變了,其余全部保持共享。這個惰性復制的直觀感受,比讀十遍文檔都管用。4.3 實驗二用 smaps 觀察共享與私有內(nèi)存的變化pagemap 需要 root,在沒有 root 的環(huán)境里可以用 smaps 觀察同樣的現(xiàn)象。思路是fork 前記錄父進程某段匿名映射的Rss和Pss,fork 后子進程寫一遍,再回到父進程看這些數(shù)值怎么變。# 在父進程里執(zhí)行,先看初始狀態(tài) grep -A 25 /dev/zero (deleted)\|\[anon\] /proc/self/smaps | head -40更實用的是寫個小腳本,直接對某個 PID 匯總pid$1 awk /^[0-9a-f]-[0-9a-f] / { name $0 } /^Rss:/ { rss $2 } /^Pss:/ { pss $2 } /^Shared_Clean:/ { sc $2 } /^Shared_Dirty:/ { sd $2 } /^Private_Clean:/{ pc $2 } /^Private_Dirty:/{ pd $2 } END { printf Rss%d kB Pss%d kB\n, rss, pss printf Shared_Clean%d Shared_Dirty%d\n, sc, sd printf Private_Clean%d Private_Dirty%d\n, pc, pd } /proc/$pid/smaps關鍵看點在于Pss和Rss的差異。Rss是這段區(qū)間有多少頁在內(nèi)存里,共享頁會被每個進程各算一次;Pss是按共享比例分攤后,這段區(qū)間實際上占了多少物理內(nèi)存,兩個進程共享一頁,每個進程只算半頁。所以如果一個進程和另一個進程大量共享內(nèi)存,Rss 會虛高,Pss 才是準的。實測下來,一個 fork 出來的子進程如果只讀不寫,它在父進程匿名區(qū)間上的Shared_Clean會上去,Private_Dirty保持很低一旦開始寫,Private_Dirty就一節(jié)一節(jié)往上爬,爬的速度取決于它實際寫了多少頁。這個增長曲線是階梯狀的,不是線性的,因為復制是按頁觸發(fā)的。4.4 實驗三把頁表層級也數(shù)一遍如果你想驗證多級頁表不為空洞付錢這個說法,可以做一個簡單的對比一個進程只mmap一頁并訪問,和mmap一大片并全部訪問,看看頁表占用的差異。從/proc/pid/status里的VmPTE字段能看到頁表本身消耗了多少內(nèi)存grep -E VmSize|VmRSS|VmPTE|VmPMD /proc/pid/statusVmPTE是頁表頁的總量(單位 kB),VmPMD是上層頁表頁的量。一個只映射幾頁的進程,VmPTE通常是 4 的倍數(shù)(每張 PT 頁 4KB),VmPMD大概十幾到幾十 kB(因為進程總有代碼段、棧、堆等若干區(qū)域,每個區(qū)域至少要掛一條通路)。當你 mmap 幾百 MB 并逐頁訪問之后,VmPTE會明顯上漲,漲幅大約等于映射字節(jié)數(shù) ÷ 2MB × 4KB,也就是每覆蓋 2MB 就要多一張 PT 頁。這個比例你可以自己算一下驗證,我算過幾次都對得上。5. 常見問題與排查技巧實錄5.1 進程內(nèi)存持續(xù)上漲,是泄漏還是 COW這是我最常被問到的一類問題。表現(xiàn)是服務跑著跑著 RSS 漲上去,但代碼里查不到明顯的泄漏點,重啟就恢復。這種情況下我會按下面這個順序排查。先看是匿名頁還是文件頁。直接讀 smaps,把Private_Dirty和Private_Clean分別匯總。Private_Dirty高說明是程序自己分配的內(nèi)存,大概率是真正的泄漏或者緩存無界增長;Private_Clean高說明是映射的文件頁,通常是代碼段或者 mmap 的文件,不算問題。再看是不是 COW 導致的雙份計賬。如果進程是 fork 模型(比如 Perl、Python 的多進程并發(fā)模型),父進程占的內(nèi)存在 fork 后會被子進程共享,fork 出來的子進程如果寫了大量頁,每寫一頁就多出一份物理內(nèi)存。這種情況Rss會漲,但Pss長得沒那么快,而且父進程和子進程的Private_Dirty會同時增長。解決辦法通常是改用posix_spawn或者線程模型,或者限制子進程生命周期。最后看是不是堆碎片。malloc的 RSS 漲但VmSize不漲,說明是已釋放的頁沒有歸還給操作系統(tǒng)。glibc 的malloc在很多情況下不會立刻munmap,尤其是堆頂以下的空閑塊?？梢杂胢alloc_trim(0)主動歸還,或者配置M_MMAP_THRESHOLD讓大塊分配直接走mmap。5.2 地址對齊與段錯誤的那些坑虛擬地址空間相關的段錯誤,有一大半和對齊、權限標志有關,我把常見的幾種列在下面。mmap返回的地址一定是頁對齊的,但如果你自己算偏移,很容易算出非對齊地址。比如想映射文件偏移 5000 字節(jié)的位置,mmap的offset參數(shù)必須是 4096 的倍數(shù),因為內(nèi)核是按頁映射的,不支持的偏移會直接返回MAP_FAILED并置EINVAL。正確做法是把偏移向下對齊到頁邊界,然后拿返回值加余數(shù)。另一個坑是PROT_WRITE和MAP_SHARED的組合。用MAP_SHARED映射一個只讀文件卻要求寫權限,mmap會失敗;但如果用MAP_PRIVATE,寫權限是允許的,只是寫了之后不會反映到文件。很多人在這里被卡住,以為是權限問題,其實是映射類型選錯了。還有一個隱蔽的坑是棧溢出。主線程棧默認 8MB,如果函數(shù)里開了個大數(shù)組,或者遞歸太深,會撞到棧底下面的保護頁,觸發(fā)段錯誤。這種錯誤的表現(xiàn)是地址接近0x7fff...的邊界,和堆、映射區(qū)的錯誤很好區(qū)分。定位方法是看 core dump 里的rsp值和 maps 里棧區(qū)間的起止地址。5.3 常見問題速查我把這幾年處理過的相關問題整理成一張表,方便你出問題時先對號入座?，F(xiàn)象大概率原因排查手段處理方式同一地址在兩個進程里值不一樣正常,虛擬地址獨立打 PFN 對比無需處理,理解機制即可fork 后 RSS 翻倍COW 后子進程大量寫看 smaps 的 Private_Dirty改模型或減少子進程寫fork 耗時隨內(nèi)存線性增長頁表復制開銷計時 fork 前后的耗時用posix_spawn規(guī)避內(nèi)存漲了但 VmSize 沒變堆內(nèi)碎片看VmRSS與VmData差值malloc_trim或換分配器大頁開啟后內(nèi)存暴漲大頁 COW 復制 2MB看AnonHugePages字段MADV_NOHUGEPAGE局部禁用mmap 返回 MAP_FAILED偏移未頁對齊 / 權限沖突看 errno偏移向下對齊,檢查 flag段錯誤地址在 0x7fff 附近棧溢出看 core 里的 rsp加大?；蛴枚言L問已 unmap 的地址懸垂指針用mmap加MAP_FIXED_NOREPLACE保護加內(nèi)存檢測工具提示讀/proc/self/pagemap拿到的物理頁號在新內(nèi)核上對非 root 用戶是清零的。這不是 bug,是有意為之。你要是發(fā)現(xiàn)查出來全是 0,先確認是不是忘了sudo。注意/proc/pid/smaps的讀取開銷不小,尤其對大內(nèi)存進程。線上環(huán)境頻繁讀會明顯增加內(nèi)核態(tài) CPU 占用,采樣間隔別低于十幾秒。5.4 幾個我踩過的坑第一個是關于pagemap的偏移計算。我一開始寫成(addr / 4096) * 8,結果因為addr是void*,在 32 位編譯下沒問題,64 位下截斷出過怪問題。后來統(tǒng)一改成((unsigned long)addr 12) * 8,再轉(zhuǎn)off_t,才徹底穩(wěn)定。這種小地方不注意,查起來能耗掉半天。第二個是關于 COW 的測量時機。早期我做實驗時,在 fork 之后立刻讀子進程的 PFN,發(fā)現(xiàn)和父進程一樣,還以為 COW 沒生效。后來才想明白,fork 那一刻本來就不該復制,復制發(fā)生在寫的時候。所以我現(xiàn)在的實驗腳本都是fork → 讀 → 寫 → 再讀,分三個時間點采樣,才看得到完整的變化過程。第三個是關于大頁的意外開啟。有次壓測一個 fork 密集型服務,發(fā)現(xiàn)內(nèi)存比預期多用了將近一倍,查了半天代碼沒找到問題,最后看AnonHugePages才發(fā)現(xiàn)系統(tǒng)默認開了透明大頁,每次 COW 都復制 2MB。關掉之后內(nèi)存立刻回到預期水平。這件事之后我養(yǎng)成了習慣凡是 fork 密集的服務,上線前必查一遍大頁配置。第四個是 TLB 刷新的問題。在做用戶態(tài)共享內(nèi)存的優(yōu)化時,我嘗試手工改頁表來共享頁面,結果發(fā)現(xiàn)改了之后另一個進程讀到的還是舊數(shù)據(jù)。原因就是 TLB 沒刷。后來改成走正規(guī)的mmap(MAP_SHARED)路徑,雖然多一層內(nèi)核調(diào)用,但省掉了所有這類心智負擔。這件事讓我徹底相信能在用戶態(tài)用標準接口解決的事,別去碰頁表。最后分享一個我平時做內(nèi)存問題定位的順序,不一定最優(yōu),但很省事先用VmSize和VmRSS的差值判斷是申請了沒用還是用了沒還;再用Private_Dirty判斷是匿名內(nèi)存還是文件頁;然后用Pss修正共享帶來的誤判;最后才上pagemap和 core dump 這種重武器。多數(shù)情況下前兩步就能把范圍縮到很小,真要讀到頁表一級的問題,其實一年也遇不上幾次。 進程地址空間、頁表與寫時拷貝：原理拆解與實驗驗證
聊進程地址空間這件事我一般不喜歡從教科書上那張代碼段、數(shù)據(jù)段、堆、棧的示意圖講起因為那張圖太干凈了,干凈到看不出真實系統(tǒng)里那些別扭的取舍。我更愿意先拋一個問題如果一個進程拿到的地址就是物理內(nèi)存里的真實地址,它敢不敢隨便用答案顯然是不敢。它不僅不敢隨便用,連自己該用哪一塊都沒法事先知道——因為同一時刻可能有幾十上百個進程在跑,誰先來誰后到、誰大誰小,全都不確定。進程地址空間、虛擬地址、頁表、寫時拷貝這一整套機制,本質(zhì)上就是給這個混亂場面建立秩序的工具。搞嵌入式的同學可能覺得這些東西離自己很遠,但只要你的代碼跑在帶 MMU 的芯片上、只要你用過fork、只要你的程序莫名其妙漲過內(nèi)存,這套機制就在你腳下。這篇內(nèi)容我打算把地址空間為什么存在頁表怎么把映射做成硬件能查的表寫時拷貝到底省了什么、又偷偷付出了什么這幾件事掰開講,再配三個能直接跑的驗證實驗,讓你不用只靠想象去理解它們。1. 先把地址這件事說透虛擬地址空間到底解決了什么問題1.1 從一段裸機代碼說起物理地址直編的四個坑在單片機上寫程序的時候,我們經(jīng)常是這么干的*(volatile uint32_t *)0x40001000 1;直接把某個外設寄存器地址寫進代碼里。這種寫法在單任務、無 MMU 的環(huán)境下毫無問題,因為整個系統(tǒng)只有一份地址空間,誰也不會跟你搶。但一旦把場景換成多任務操作系統(tǒng),這種物理地址直編的思路立刻會撞上四面墻。第一面墻是隔離。進程 A 在地址 0x1000 處存了個關鍵結構體,進程 B 因為指針算錯也往 0x1000 寫,結果 A 的數(shù)據(jù)被悄悄改掉,而且這種 bug 極難定位——A 崩潰的時候 B 早就跑完了。第二面墻是重定位。編譯器在編譯期根本不知道自己的代碼會被加載到物理內(nèi)存的哪個位置,如果按固定地址生成跳轉(zhuǎn)指令,加載位置一變?nèi)P皆輸。第三面墻是稀疏使用。一個進程可能只用了 1MB 內(nèi)存,但它需要一段連續(xù)的大地址區(qū)間來放棧、放堆,如果按物理地址分配,就得真的預留那么多連續(xù)物理頁,浪費得離譜。第四面墻是共享與回收。多個進程跑同一個可執(zhí)行文件,按理說代碼段應該只有一份,但物理地址直編的模型下沒法表達兩個進程的某段地址指向同一塊物理內(nèi)存這個概念。虛擬地址空間就是把這幾面墻一次性推倒的方案。每個進程都擁有一份獨立的、從 0 開始一直延伸到某個上限的地址空間,進程里所有指針、所有跳轉(zhuǎn)、所有malloc返回的值,都是這個空間里的虛擬地址。真實物理內(nèi)存在哪里、有多少、是不是連續(xù)的,進程完全不需要知道,也完全無法知道。1.2 虛擬地址空間的本質(zhì)一層可編程的映射我習慣把虛擬地址空間理解成一張可編程的對照表。表的左邊是虛擬頁號,右邊是物理頁號,中間還掛著幾個權限位。CPU 每次訪存,MMU 拿虛擬地址去查這張表,查到了就換成物理地址去訪問內(nèi)存,查不到或者權限不對就拋異常。這張表由操作系統(tǒng)維護,進程自己改不了,這就是隔離的物理基礎。這層抽象帶來的好處是連鎖反應式的。因為映射關系是可編程的,操作系統(tǒng)可以在進程啟動時把可執(zhí)行文件的代碼段映射到任意物理頁上,于是位置無關加載變成了默認行為。因為映射是頁粒度的,一個進程的地址空間里可以有大片沒有映射的空洞,訪問到就觸發(fā)缺頁異常,操作系統(tǒng)再決定是分配一頁、還是從磁盤讀回來、還是干脆殺掉進程,于是按需分配成為可能。因為映射表里可以記錄這一頁是只讀的,多個進程可以共享同一塊物理內(nèi)存,誰想寫就觸發(fā)異常,內(nèi)核再給誰單獨復制一份,于是共享庫和寫時拷貝順理成章。我特別想強調(diào)一點虛擬地址空間這套東西之所以能成立,是因為它把進程看到的世界和真實的世界徹底解耦了。進程以為自己獨占了一整塊連續(xù)的、從 0 開始的內(nèi)存;內(nèi)核知道這全是假的,物理頁散落在各處,隨時可以被換出、被遷移、被共享。這種謊言不是欺騙,而是一種極其成功的接口設計——它讓上層程序員可以用最簡單的心智模型寫代碼,把復雜性全部壓到內(nèi)核和硬件那一層。1.3 進程地址空間布局一張圖背后藏著的信息在 64 位 Linux 上,一個典型進程的虛擬地址空間大致長這樣區(qū)域內(nèi)容增長方向典型說明代碼段 text機器指令固定通常只讀、可執(zhí)行,多進程共享數(shù)據(jù)段 data已初始化全局/靜態(tài)變量固定可讀寫,私有BSS未初始化全局/靜態(tài)變量固定不占文件空間,加載時清零堆 heapmalloc小對象向高地址由brk擴展,連續(xù)映射區(qū) mmap大塊malloc、共享庫、文件映射向低地址從高地址往下長,靈活棧 stack局部變量、調(diào)用幀向低地址主線程默認 8MBvdso/vvar內(nèi)核提供的高頻調(diào)用實現(xiàn)固定免去系統(tǒng)調(diào)用開銷這張表里有兩個細節(jié)是很多人忽略的。第一,堆和映射區(qū)是相向生長的。malloc小內(nèi)存走brk把堆頂往高推,大內(nèi)存(默認閾值 128KB 左右,由M_MMAP_THRESHOLD控制)走mmap在高地址區(qū)找一塊空地,兩者中間留出巨大空隙,誰先撞上誰觸發(fā)擴展或失敗。第二,代碼段和共享庫是真正共享物理頁的,不是各自復制一份。你在 /proc 的 smaps 里看到共享庫的Shared_Clean很大,而Private_Dirty很小,就是這個原因。還有一個容易誤解的點64 位下用戶態(tài)可用的虛擬地址并不是完整的 64 位,而是 48 位(4 級頁表)或者 57 位(5 級頁表,需要顯式開啟)。低半?yún)^(qū)屬于用戶進程,高半?yún)^(qū)留給內(nèi)核,中間是一條不可跨越的鴻溝。所以你在 64 位程序里打印指針,看到的基本都是0x0000_7fxx_xxxx_xxxx這樣開頭的值,不會是0xffff_...。2. 頁表把映射做成硬件可查表2.1 為什么是頁而不是字節(jié)有人會問既然要做映射,為什么不做成字節(jié)粒度的映射表,一字節(jié)虛擬地址對應一字節(jié)物理地址原因很直接——這張表會大到無法存儲。假設一個進程有 4GB 虛擬空間,字節(jié)粒度映射表每項至少 8 字節(jié),那光映射表就要 32GB,比地址空間本身還大,荒謬。頁粒度是一個甜點。以 4KB 頁為例,4GB 地址空間需要 100 萬個表項,每項 8 字節(jié),總共 8MB。勉強能接受,但還不夠好——因為絕大多數(shù)進程根本用不滿 4GB,為空洞付 8MB 代價太虧。這就逼出了下一層的優(yōu)化分級。而如果選更大的頁,比如 2MB,表項數(shù)量降到 2048 個,表只有 16KB,但內(nèi)部碎片會變嚴重——一個進程只用了 1 字節(jié)也得占 2MB。4KB 是歷史上軟硬件妥協(xié)出來的結果,和磁盤扇區(qū)、內(nèi)存顆粒的行緩沖都有關系,至今仍是絕大多數(shù)體系結構的默認頁大小。這里有個數(shù)值得記住4KB 2^12,所以虛擬地址的低 12 位是頁內(nèi)偏移,永遠不會被翻譯,原樣透傳到物理地址的低 12 位。這個設計讓翻譯這件事變得極其簡單——MMU 只需要處理高位,低位直接抄過去。2.2 多級頁表用時間換空間的經(jīng)典取舍單級頁表的問題是,一張表必須連續(xù)存放,而它要覆蓋整個地址空間。48 位虛擬地址、4KB 頁,需要 2^36 個表項,每項 8 字節(jié),單張表就是 512GB。這顯然不可能。解決辦法是把這張大表切碎、分層,變成一棵樹。x86-64 的 4 級頁表是這么切的把 48 位虛擬地址拆成 5 段,[47:39] [38:30] [29:21] [20:12] [11:0],前四段各 9 位,正好每段能索引 512 個表項;最后 12 位是頁內(nèi)偏移。每張頁表頁正好 4KB,裝 512 個 8 字節(jié)表項,大小嚴絲合縫。層級索引位單表容量單表覆蓋范圍表項指向PML447:39512 項512 × 512GB 256TBPDPT 頁PDPT38:30512 項512 × 1GB 512GBPD 頁PD29:21512 項512 × 2MB 1GBPT 頁PT20:12512 項512 × 4KB 2MB物理頁這套設計的精妙之處在于不為空洞付錢。一個進程如果只在某個 2MB 區(qū)間里用了幾頁,那么 PML4、PDPT、PD 各需要一張表(各 4KB),PT 也需要一張(4KB),總共 16KB 頁表就能支撐起這幾頁的映射;而地址空間里其他廣袤的空白區(qū)域,對應的頁表頁根本不存在,頂級表項直接標記為未映射。這就是分級頁表用空間效率換來的代價——查表要爬樹。爬樹的成本是可以量化的。一次 TLB 未命中,MMU 要依次讀 PML4、PDPT、PD、PT 四張表,每讀一張都是一次內(nèi)存訪問(這些表都在內(nèi)存里,只是被硬件緩存加速),最后才拿到物理頁號,再去讀真正的數(shù)據(jù)。最壞情況是 5 次內(nèi)存訪問才能拿到一個字節(jié)。如果每次都這樣,程序會慢到?jīng)]法用。所以 CPU 里專門放了一個 TLB(Translation Lookaside Buffer),緩存最近用過的虛擬頁號到物理頁號的對應關系。TLB 命中的時候翻譯幾乎是零成本的,這也是為什么局部性好的程序跑得快——不只是緩存命中率高,頁表翻譯的緩存命中率也高。2.3 頁表項里到底存了什么一張頁表項是 8 字節(jié),但物理頁號只占其中一部分,剩下的位全是標志位。理解這些位,才能理解內(nèi)核的很多行為。以 x86-64 的 4KB 頁表項為例位名稱含義實際影響0P存在位為 0 表示該頁不在內(nèi)存,訪問觸發(fā)缺頁1R/W讀寫位為 0 時寫操作觸發(fā)保護異常2U/S用戶/內(nèi)核位為 0 時用戶態(tài)訪問觸發(fā)異常3PWT寫通影響緩存策略,普通應用很少關心4PCD禁止緩存用于映射設備內(nèi)存5A已訪問硬件置位,內(nèi)核據(jù)此判斷頁的活躍度6D已臟寫過的頁,換出時需要回寫7PS大頁標志在 PD 層置位表示 2MB 大頁8G全局TLB 不隨 CR3 切換刷新12-51物理頁號高位地址指向?qū)嶋H物理頁63XD禁止執(zhí)行置位后該頁不可執(zhí)行,NX 保護的來源我經(jīng)常拿R/W位來講寫時拷貝,因為它是整套機制里最四兩撥千斤的一個位。內(nèi)核在fork之后把所有可寫的私有頁在父子兩個進程的頁表里都標成只讀,數(shù)據(jù)本身一個字節(jié)都沒動;等到某一方真的去寫,硬件發(fā)現(xiàn)R/W0,拋出保護異常,內(nèi)核在異常處理里再決定是復制一頁還是恢復可寫。整個復制動作被推遲到了真正需要的那一刻,而且只復制真正被寫的那一頁。A位和D位也有講究。內(nèi)核的頁面回收算法需要知道哪些頁最近被訪問過,硬件每次訪問都會把A置 1,內(nèi)核掃描時讀一下、清一下,就能近似判斷出頁的熱度。這不是精確統(tǒng)計,但足夠用,而且完全不占用軟件開銷。這種讓硬件順手干活的思路在體系結構里到處都是。2.4 TLB 與頁表遍歷的真實開銷很多人學完頁表會有個模糊印象查表很慢,但 TLB 救了它。這個說法沒錯,但太籠統(tǒng)。我想給幾個更具體的數(shù),便于你判斷什么時候該關心它。TLB 通常分兩級L1 dTLB 只有幾十到一百多個條目,覆蓋幾 MB 到幾百 KB;L2 TLB 稍大,幾千條,覆蓋幾 MB 到幾十 MB。也就是說,如果一個程序的工作集(活躍頁數(shù))小于 L2 TLB 的覆蓋范圍,翻譯開銷基本可以忽略;一旦工作集超過這個范圍,TLB 開始頻繁未命中,每次未命中要爬 4 級頁表,性能會掉一個臺階。這就是大頁存在的理由。2MB 大頁只需要 PD 層一個表項,不需要 PT 層,一次 TLB 表項就能覆蓋 2MB 而不是 4KB,覆蓋率提升 512 倍。數(shù)據(jù)庫、JVM 這類吃內(nèi)存大戶經(jīng)常開透明大頁,收益主要就在這里。代價是大頁內(nèi)部的碎片沒法回收,內(nèi)存緊張時反而會拖累系統(tǒng),所以很多場景又會關掉它。這是一個很典型的沒有銀彈案例。還有一個常被忽略的成本切換進程要換頁表基址。x86 上頁表基址存在 CR3 寄存器里,進程切換時內(nèi)核寫 CR3 指向新進程的 PML4,這個動作會讓 TLB 里大部分條目失效(除非用了 PCID 之類的機制給條目打標簽)。所以高頻的進程切換不僅浪費在保存寄存器上,還浪費在 TLB 冷啟動上。這也是為什么線程切換比進程切換便宜——同一地址空間,CR3 不用換。3. 寫時拷貝fork 性能的一次關鍵妥協(xié)3.1 fork 為什么要拷貝,又為什么不想拷貝fork的語義是創(chuàng)建一個和自己一模一樣的子進程,最直白的實現(xiàn)就是把父進程的所有內(nèi)存逐字節(jié)復制一份給子進程。這在小進程上沒問題,但一個占了幾個 GB 的服務進程 fork 一次,復制幾 GB 數(shù)據(jù),耗時可能到秒級,期間父進程還得停下來配合。這在早年的 Unix 上就是個大問題。寫時拷貝的思路是先別復制,讓父子共享同一份物理頁,把頁表里的寫權限全部收掉。如果父子倆從此只是讀,那就一直共享下去,零成本;如果某一方要寫,硬件拋出保護異常,內(nèi)核在異常里才真正復制那一頁,并且只復制被寫的那一頁。這樣,fork的實際開銷從復制全部數(shù)據(jù)降級成復制頁表項,通常能快一到兩個數(shù)量級。但這里有個被嚴重低估的事實頁表本身還是要復制的。fork的時候內(nèi)核要遍歷父進程的所有 VMA(虛擬內(nèi)存區(qū)域),為子進程建立同樣的 VMA 結構,然后遍歷頁表,把每一級的表頁也復制一份出來——因為父子進程的頁表必須各自獨立,否則一方改頁表項會影響到另一方。對一個映射了幾十 GB 內(nèi)存的進程來說,光是復制頁表頁就可能要幾百 MB 的內(nèi)存和相當可觀的時間。所以COW 讓 fork 變得免費是個錯誤認知,更準確的說法是COW 把 fork 的成本從數(shù)據(jù)量級降到了頁表量級。我給個量化的例子。假設一個進程映射了 8GB 匿名內(nèi)存,頁大小 4KB,那么頁表項有 200 萬個,PT 頁有 4000 個,加上各級上層表,頁表總大小約 16MB 左右。fork時這 16MB 要被復制,200 萬個 PTE 的R/W位要被清掉,這個遍歷本身就要幾十毫秒。相比之下 8GB 的數(shù)據(jù)復制要幾秒。差了將近兩個數(shù)量級,但絕對不是零。3.2 COW 的完整觸發(fā)鏈路想真正吃透 COW,得把從fork到某一頁被復制的完整鏈路走一遍。我用 Linux 的實現(xiàn)做參照,其他系統(tǒng)的結構大同小異。第一步,fork進入內(nèi)核,走copy_process。這里會創(chuàng)建新的 task 結構、新的 mm 結構(地址空間描述符),然后調(diào)用copy_mm。第二步,copy_mm判斷是否共享地址空間。如果是clone帶CLONE_VM標志(線程),直接共享 mm,什么都不復制;如果是fork,調(diào)用dup_mmap逐條復制 VMA。這一步會把父進程的每個 VMA 用vm_area_dup復制一份,掛到子進程的 mm 上,同時把父子雙方的 VMA 都標記為VM_MAYWRITE之類的共享狀態(tài),并建立反向映射結構。第三步,copy_page_range遍歷頁表。對每一個有效的 PTE,內(nèi)核把對應物理頁的引用計數(shù)加一,然后把父子雙方的 PTE 的R/W位清零,同時保留PTE_W在軟件位里的記錄(_PAGE_RW的軟件備份,不同內(nèi)核版本用不同方式記),以便將來恢復。注意,這里改的是父子兩份頁表,因為頁表已經(jīng)各自獨立了。第四步,某一方執(zhí)行寫操作。CPU 發(fā)現(xiàn)目標頁的 PTE 里R/W0,但頁是存在的,于是拋出 page fault,錯誤碼里帶上寫和保護違規(guī)兩個標志。第五步,內(nèi)核缺頁處理。do_page_fault拿到pt_regs和錯誤碼,判斷出這是寫保護導致的可恢復異常,進入handle_pte_fault分支,再走到do_wp_page。第六步,do_wp_page做決策。它先看這個物理頁當前的引用情況如果只有當前進程在用(引用計數(shù)為 1),說明另一方早就復制走了或者根本沒共享,那就直接把 PTE 改回可寫,什么都不復制,這叫reuse 優(yōu)化;如果還有別人在用,就分配一個新頁,把舊頁內(nèi)容memcpy過去,新頁掛到當前進程的 PTE 上,舊頁引用計數(shù)減一。第七步,更新 TLB。頁表改了之后,要刷新對應的 TLB 條目,否則 CPU 還會用舊的翻譯結果。這一步做漏了就會出現(xiàn)極難排查的數(shù)據(jù)不一致問題。這條鏈路里,do_wp_page的 reuse 判斷是關鍵的性能分水嶺。很多場景下父進程 fork 完就exec,子進程立刻換掉整個地址空間,父進程這邊根本不會有寫沖突;或者 fork 之后只有一方活著,另一方早就退出,頁的引用計數(shù)掉回 1,后續(xù)的寫就能直接復用。真正需要復制的情況,往往比想象中少。3.3 引用計數(shù)與頁生命周期COW 能成立,前提是內(nèi)核精確知道這一頁現(xiàn)在被幾個地方引用著。Linux 用struct page里的_refcount(總引用數(shù),包括頁表引用、page cache 引用、內(nèi)核內(nèi)部引用)和_mapcount(被多少個用戶頁表映射)兩個字段共同管理。fork時,每個被共享的可寫頁的_mapcount加一,_refcount加一。子進程退出時,它映射的每一頁都要減回去。觸發(fā) COW 復制時,新頁的計數(shù)從零開始建立,舊頁的計數(shù)減一。如果減到_mapcount為 1,意味著只剩一個映射者,再寫就可以直接復用。這套計數(shù)機制出問題時的表現(xiàn)很有迷惑性。引用計數(shù)漏加會導致頁被提前釋放,表現(xiàn)為隨機的內(nèi)存損壞或者莫名的段錯誤;引用計數(shù)多加會導致頁永遠回收不掉,表現(xiàn)為內(nèi)存持續(xù)上漲但查不到泄漏點。我見過一個案例,某開發(fā)者在驅(qū)動里手工改 PTE 實現(xiàn)共享內(nèi)存,忘了同步加_mapcount,結果系統(tǒng)跑幾小時后必然崩,查了兩天才定位到。還有一個容易忽略的點COW 和文件映射的交互。文件私有映射(MAP_PRIVATE)在被寫時也走 COW,但它多一層語義——寫完之后這頁就變成了匿名頁,不再和文件關聯(lián),后續(xù)的文件修改不會反映過來。這個行為很多人以為是 bug,其實是設計如此。3.4 COW 不是銀彈坑在哪寫時拷貝用得不當會帶來幾個典型問題,我在實際項目里都踩過。第一個坑是大頁 COW。如果開了透明大頁,一個 2MB 的大頁被 COW,復制的是整整 2MB 而不是 4KB。一個進程如果頻繁 fork 且每次都寫一點點,開了大頁之后內(nèi)存占用和復制開銷都會暴漲。這種情況要么關掉大頁,要么用madvise(MADV_NOHUGEPAGE)在特定區(qū)域禁掉。第二個坑是內(nèi)存賬算不準。父子進程共享的頁,在各自的 smaps 里都會算進 RSS,于是把父子的 RSS 加起來會遠大于實際物理占用。要準確看共享情況,得看Pss(按共享比例分攤)而不是Rss。做容量規(guī)劃的時候如果只看 RSS,會嚴重高估。第三個坑是fork 之后立刻大改。有些程序 fork 出子進程后馬上在子進程里遍歷修改一個大數(shù)組,這時候每一頁都觸發(fā)一次 COW,等于把復制成本從 fork 時刻挪到了運行時刻,總成本一點沒省,而且還多了幾百萬次缺頁異常的開銷。這種場景不如直接vfork加exec,或者用posix_spawn。第四個坑是和內(nèi)存回收打架。COW 產(chǎn)生的匿名頁在內(nèi)存緊張時會被換出,但父子共享期間頁被標成只讀,回收路徑要特殊處理。極端情況下,內(nèi)存壓力大時 COW 缺頁會因為要先回收內(nèi)存才能分配新頁,導致延遲抖動明顯。這個在延遲敏感的服務里很致命。4. 動手驗證把抽象的東西量出來4.1 環(huán)境與工具準備光看文字容易產(chǎn)生我懂了的錯覺,所以我建議你親手跑一遍下面的實驗。環(huán)境要求很簡單一臺 64 位 Linux,裝了 gcc,有 root 權限(讀 pagemap 需要),內(nèi)核版本 4.x 以上。核心工具就三個/proc/self/pagemap用來查虛擬頁對應的物理頁號;/proc/self/maps看虛擬地址區(qū)間;/proc/self/smaps看每個區(qū)間的詳細內(nèi)存賬。pagemap 的格式是一個大文件,每 8 字節(jié)對應一個虛擬頁,文件偏移 虛擬頁號 × 8。表項里 bit 63 是頁是否存在,bit 0-54 是物理頁號。注意從 4.x 某個版本開始,非特權用戶讀到的物理頁號字段會被清零,所以必須用 root 跑。4.2 實驗一同一虛擬地址在不同進程指向不同物理頁這個實驗要驗證的核心事實是fork 之后父子進程打印出來的指針值完全一樣,但通過 COW 之后它們指向的物理頁不一樣了。#define _GNU_SOURCE #include stdio.h #include stdlib.h #include unistd.h #include fcntl.h #include sys/mman.h #include sys/wait.h static unsigned long long pfn_of(void *addr) { unsigned long long entry 0; int fd open(/proc/self/pagemap, O_RDONLY); if (fd 0) { perror(open pagemap); return 0; } off_t off (off_t)(((unsigned long)addr 12) * 8); if (pread(fd, entry, sizeof(entry), off) ! sizeof(entry)) { close(fd); return 0; } close(fd); if (!(entry (1ULL 63))) /* 頁不在內(nèi)存 */ return 0; return entry ((1ULL 55) - 1); } int main(void) { size_t page (size_t)sysconf(_SC_PAGESIZE); int *p mmap(NULL, page, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (p MAP_FAILED) { perror(mmap); return 1; } *p 0x1234; printf(parent pid%-6d va%p pfn%-8llu val0x%x\n, getpid(), (void *)p, pfn_of(p), *p); pid_t pid fork(); if (pid 0) { perror(fork); return 1; } if (pid 0) { printf(child pid%-6d va%p pfn%-8llu val0x%x\n, getpid(), (void *)p, pfn_of(p), *p); *p 0x5678; /* 觸發(fā) COW */ printf(child after-write va%p pfn%-8llu val0x%x\n, (void *)p, pfn_of(p), *p); _exit(0); } waitpid(pid, NULL, 0); printf(parent after-child va%p pfn%-8llu val0x%x\n, (void *)p, pfn_of(p), *p); return 0; }編譯和運行gcc -O0 -g -o cow_demo cow_demo.c sudo ./cow_demo我用-O0是為了防止編譯器把*p的讀寫優(yōu)化掉。跑出來的結果應該長這樣(具體頁號每次不同)parent pid12001 va0x7f3a2c000000 pfn284117 val0x1234 child pid12002 va0x7f3a2c000000 pfn284117 val0x1234 child after-write va0x7f3a2c000000 pfn631842 val0x5678 parent after-child va0x7f3a2c000000 pfn284117 val0x1234三個關鍵結論全在這幾行里。虛擬地址完全一致,父子倆都以為自己用的是0x7f3a2c000000。fork 剛完成時物理頁號也一致,說明數(shù)據(jù)確實沒被復制。子進程寫完之后物理頁號變了,父進程的沒變,而且父進程讀到的值還是0x1234,說明 COW 只復制了被寫的那一頁,沒有影響另一方。這個結果和原理對得上,你才算真的理解了。這個實驗我建議你多跑幾次,把pfn_of換成查多個頁,比如一次性 mmap 1MB(256 頁),子進程只寫第 0 頁和第 100 頁,看看有多少頁的物理號變了。你會發(fā)現(xiàn)只有那兩頁變了,其余全部保持共享。這個惰性復制的直觀感受,比讀十遍文檔都管用。4.3 實驗二用 smaps 觀察共享與私有內(nèi)存的變化pagemap 需要 root,在沒有 root 的環(huán)境里可以用 smaps 觀察同樣的現(xiàn)象。思路是fork 前記錄父進程某段匿名映射的Rss和Pss,fork 后子進程寫一遍,再回到父進程看這些數(shù)值怎么變。# 在父進程里執(zhí)行,先看初始狀態(tài) grep -A 25 /dev/zero (deleted)\|\[anon\] /proc/self/smaps | head -40更實用的是寫個小腳本,直接對某個 PID 匯總pid$1 awk /^[0-9a-f]-[0-9a-f] / { name $0 } /^Rss:/ { rss $2 } /^Pss:/ { pss $2 } /^Shared_Clean:/ { sc $2 } /^Shared_Dirty:/ { sd $2 } /^Private_Clean:/{ pc $2 } /^Private_Dirty:/{ pd $2 } END { printf Rss%d kB Pss%d kB\n, rss, pss printf Shared_Clean%d Shared_Dirty%d\n, sc, sd printf Private_Clean%d Private_Dirty%d\n, pc, pd } /proc/$pid/smaps關鍵看點在于Pss和Rss的差異。Rss是這段區(qū)間有多少頁在內(nèi)存里,共享頁會被每個進程各算一次;Pss是按共享比例分攤后,這段區(qū)間實際上占了多少物理內(nèi)存,兩個進程共享一頁,每個進程只算半頁。所以如果一個進程和另一個進程大量共享內(nèi)存,Rss 會虛高,Pss 才是準的。實測下來,一個 fork 出來的子進程如果只讀不寫,它在父進程匿名區(qū)間上的Shared_Clean會上去,Private_Dirty保持很低一旦開始寫,Private_Dirty就一節(jié)一節(jié)往上爬,爬的速度取決于它實際寫了多少頁。這個增長曲線是階梯狀的,不是線性的,因為復制是按頁觸發(fā)的。4.4 實驗三把頁表層級也數(shù)一遍如果你想驗證多級頁表不為空洞付錢這個說法,可以做一個簡單的對比一個進程只mmap一頁并訪問,和mmap一大片并全部訪問,看看頁表占用的差異。從/proc/pid/status里的VmPTE字段能看到頁表本身消耗了多少內(nèi)存grep -E VmSize|VmRSS|VmPTE|VmPMD /proc/pid/statusVmPTE是頁表頁的總量(單位 kB),VmPMD是上層頁表頁的量。一個只映射幾頁的進程,VmPTE通常是 4 的倍數(shù)(每張 PT 頁 4KB),VmPMD大概十幾到幾十 kB(因為進程總有代碼段、棧、堆等若干區(qū)域,每個區(qū)域至少要掛一條通路)。當你 mmap 幾百 MB 并逐頁訪問之后,VmPTE會明顯上漲,漲幅大約等于映射字節(jié)數(shù) ÷ 2MB × 4KB,也就是每覆蓋 2MB 就要多一張 PT 頁。這個比例你可以自己算一下驗證,我算過幾次都對得上。5. 常見問題與排查技巧實錄5.1 進程內(nèi)存持續(xù)上漲,是泄漏還是 COW這是我最常被問到的一類問題。表現(xiàn)是服務跑著跑著 RSS 漲上去,但代碼里查不到明顯的泄漏點,重啟就恢復。這種情況下我會按下面這個順序排查。先看是匿名頁還是文件頁。直接讀 smaps,把Private_Dirty和Private_Clean分別匯總。Private_Dirty高說明是程序自己分配的內(nèi)存,大概率是真正的泄漏或者緩存無界增長;Private_Clean高說明是映射的文件頁,通常是代碼段或者 mmap 的文件,不算問題。再看是不是 COW 導致的雙份計賬。如果進程是 fork 模型(比如 Perl、Python 的多進程并發(fā)模型),父進程占的內(nèi)存在 fork 后會被子進程共享,fork 出來的子進程如果寫了大量頁,每寫一頁就多出一份物理內(nèi)存。這種情況Rss會漲,但Pss長得沒那么快,而且父進程和子進程的Private_Dirty會同時增長。解決辦法通常是改用posix_spawn或者線程模型,或者限制子進程生命周期。最后看是不是堆碎片。malloc的 RSS 漲但VmSize不漲,說明是已釋放的頁沒有歸還給操作系統(tǒng)。glibc 的malloc在很多情況下不會立刻munmap,尤其是堆頂以下的空閑塊?？梢杂胢alloc_trim(0)主動歸還,或者配置M_MMAP_THRESHOLD讓大塊分配直接走mmap。5.2 地址對齊與段錯誤的那些坑虛擬地址空間相關的段錯誤,有一大半和對齊、權限標志有關,我把常見的幾種列在下面。mmap返回的地址一定是頁對齊的,但如果你自己算偏移,很容易算出非對齊地址。比如想映射文件偏移 5000 字節(jié)的位置,mmap的offset參數(shù)必須是 4096 的倍數(shù),因為內(nèi)核是按頁映射的,不支持的偏移會直接返回MAP_FAILED并置EINVAL。正確做法是把偏移向下對齊到頁邊界,然后拿返回值加余數(shù)。另一個坑是PROT_WRITE和MAP_SHARED的組合。用MAP_SHARED映射一個只讀文件卻要求寫權限,mmap會失敗;但如果用MAP_PRIVATE,寫權限是允許的,只是寫了之后不會反映到文件。很多人在這里被卡住,以為是權限問題,其實是映射類型選錯了。還有一個隱蔽的坑是棧溢出。主線程棧默認 8MB,如果函數(shù)里開了個大數(shù)組,或者遞歸太深,會撞到棧底下面的保護頁,觸發(fā)段錯誤。這種錯誤的表現(xiàn)是地址接近0x7fff...的邊界,和堆、映射區(qū)的錯誤很好區(qū)分。定位方法是看 core dump 里的rsp值和 maps 里棧區(qū)間的起止地址。5.3 常見問題速查我把這幾年處理過的相關問題整理成一張表,方便你出問題時先對號入座?，F(xiàn)象大概率原因排查手段處理方式同一地址在兩個進程里值不一樣正常,虛擬地址獨立打 PFN 對比無需處理,理解機制即可fork 后 RSS 翻倍COW 后子進程大量寫看 smaps 的 Private_Dirty改模型或減少子進程寫fork 耗時隨內(nèi)存線性增長頁表復制開銷計時 fork 前后的耗時用posix_spawn規(guī)避內(nèi)存漲了但 VmSize 沒變堆內(nèi)碎片看VmRSS與VmData差值malloc_trim或換分配器大頁開啟后內(nèi)存暴漲大頁 COW 復制 2MB看AnonHugePages字段MADV_NOHUGEPAGE局部禁用mmap 返回 MAP_FAILED偏移未頁對齊 / 權限沖突看 errno偏移向下對齊,檢查 flag段錯誤地址在 0x7fff 附近棧溢出看 core 里的 rsp加大?；蛴枚言L問已 unmap 的地址懸垂指針用mmap加MAP_FIXED_NOREPLACE保護加內(nèi)存檢測工具提示讀/proc/self/pagemap拿到的物理頁號在新內(nèi)核上對非 root 用戶是清零的。這不是 bug,是有意為之。你要是發(fā)現(xiàn)查出來全是 0,先確認是不是忘了sudo。注意/proc/pid/smaps的讀取開銷不小,尤其對大內(nèi)存進程。線上環(huán)境頻繁讀會明顯增加內(nèi)核態(tài) CPU 占用,采樣間隔別低于十幾秒。5.4 幾個我踩過的坑第一個是關于pagemap的偏移計算。我一開始寫成(addr / 4096) * 8,結果因為addr是void*,在 32 位編譯下沒問題,64 位下截斷出過怪問題。后來統(tǒng)一改成((unsigned long)addr 12) * 8,再轉(zhuǎn)off_t,才徹底穩(wěn)定。這種小地方不注意,查起來能耗掉半天。第二個是關于 COW 的測量時機。早期我做實驗時,在 fork 之后立刻讀子進程的 PFN,發(fā)現(xiàn)和父進程一樣,還以為 COW 沒生效。后來才想明白,fork 那一刻本來就不該復制,復制發(fā)生在寫的時候。所以我現(xiàn)在的實驗腳本都是fork → 讀 → 寫 → 再讀,分三個時間點采樣,才看得到完整的變化過程。第三個是關于大頁的意外開啟。有次壓測一個 fork 密集型服務,發(fā)現(xiàn)內(nèi)存比預期多用了將近一倍,查了半天代碼沒找到問題,最后看AnonHugePages才發(fā)現(xiàn)系統(tǒng)默認開了透明大頁,每次 COW 都復制 2MB。關掉之后內(nèi)存立刻回到預期水平。這件事之后我養(yǎng)成了習慣凡是 fork 密集的服務,上線前必查一遍大頁配置。第四個是 TLB 刷新的問題。在做用戶態(tài)共享內(nèi)存的優(yōu)化時,我嘗試手工改頁表來共享頁面,結果發(fā)現(xiàn)改了之后另一個進程讀到的還是舊數(shù)據(jù)。原因就是 TLB 沒刷。后來改成走正規(guī)的mmap(MAP_SHARED)路徑,雖然多一層內(nèi)核調(diào)用,但省掉了所有這類心智負擔。這件事讓我徹底相信能在用戶態(tài)用標準接口解決的事,別去碰頁表。最后分享一個我平時做內(nèi)存問題定位的順序,不一定最優(yōu),但很省事先用VmSize和VmRSS的差值判斷是申請了沒用還是用了沒還;再用Private_Dirty判斷是匿名內(nèi)存還是文件頁;然后用Pss修正共享帶來的誤判;最后才上pagemap和 core dump 這種重武器。多數(shù)情況下前兩步就能把范圍縮到很小,真要讀到頁表一級的問題,其實一年也遇不上幾次。