iT邦幫忙

2026 iThome 鐵人賽

DAY 6
0
自我挑戰組

從 Page Fault 到 OOM:Linux 記憶體管理 30 天拆解系列 第 6

Page fault:不是每次都是錯誤

  • 分享至 

  • xImage
  •  

很多人第一次聽到 page fault,會直覺把它當成錯誤。畢竟名字裡有 fault,看起來像程式壞掉了。但在 Linux 記憶體管理裡,page fault 很常是正常流程。它只是 CPU 發現某個虛擬位址目前沒有辦法直接轉換,於是通知 kernel 來處理。

最常見的正常 page fault 是 demand paging。process 啟動或 mmap() 一段檔案時,kernel 不一定會立刻把所有內容讀進 RAM。它可以先建立 VMA,等程式真的讀到某個 page 時才觸發 page fault。kernel 收到 fault 後,確認這個位址屬於合法 VMA,就把需要的資料載入或配置頁面,再讓程式繼續跑。

anonymous memory 也常靠 page fault 延遲配置。程式可能宣告或保留一大段位址空間,但只要沒有真的寫入,kernel 就不需要馬上分配實體頁面。第一次寫入時發生 page fault,kernel 才配置一個實體頁面,清成零,接著建立 page table mapping。

另一種重要情境是 copy-on-write。fork() 後,父子 process 一開始可以共享同一批實體頁面,並把 page table 設成唯讀。當其中一方嘗試寫入時,CPU 觸發 write fault,kernel 才複製一份頁面給寫入者。這讓 fork() 不需要一開始就複製整個 address space。

當然,page fault 也可能真的是錯誤。如果 process 存取的位址不屬於任何 VMA,或嘗試寫入唯讀區域,而且沒有 COW 這類合法處理方式,kernel 就會送出 SIGSEGV。這就是常見的 segmentation fault。

觀察 page fault 時,也要分 major fault 和 minor fault。minor fault 不需要從磁碟讀資料,例如頁面已經在記憶體中,只是還沒建立對應。major fault 則通常需要 I/O,成本高很多。如果系統 major fault 很多,可能代表工作集超過 RAM、page cache 命中率差,或 swap 正在被大量使用。

下一篇會拆 anonymous memory 和 file-backed memory。page fault 的處理方式,很大一部分取決於這個頁面背後有沒有檔案來源。


上一篇
TLB:為什麼快取位址轉換很重要
下一篇
Anonymous memory 與 file-backed memory
系列文
從 Page Fault 到 OOM:Linux 記憶體管理 30 天拆解11
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言