圖解|什么是缺頁錯誤Page Fault

3. 內存的惰性分配

以32位的Linux系統(tǒng)為例，每個進程獨立擁有4GB的虛擬地址空間，根據局部性原理沒有必要也不可能為每個進程分配4GB的物理地址空間。

64位系統(tǒng)也是一樣的道理，只不過空間尋址范圍大了很多很多倍，進程的虛擬地址空間會分為幾個部分：

實際上只有程序運行時用到了才去內存中尋找虛擬地址對應的頁幀，找不到才可能進行分配，這就是內存的惰性(延時)分配機制。

對于一個運行中的進程來說，不是所有的虛擬地址在物理內存中都有對應的頁，如圖展示了部分虛擬地址存在對應物理頁的情況：

虛擬地址空間根據固定大小一般是4KB進行劃分，物理內存可以設置不同的頁面大小，通常物理頁大小和虛擬頁大小是一樣的，本文按照物理頁4KB大小展開。

經過前面的分析，我們將面臨一個問題：如何將虛擬地址準確快速地映射到物理頁呢？

>>>高能預警 敲黑板 本段小結<<<
1. Linux的虛擬地址空間就是空頭支票，看著很大但是實際對應的物理空間只有很少的一部分。

2.內存的惰性分配是個有效的機制，可以保證內存利用率和服務器利用率，是資源合理配置的方法。

3.大量的虛擬地址到物理地址的快速準確地查詢轉換是一個難題。

4. CPU如果獲取內存中的數據

CPU并不直接和物理內存打交道，而是把地址轉換的活外包給了MMU，MMU是一種硬件電路，其速度很快，主要工作是進行內存管理，地址轉換只是它承接的業(yè)務之一。

一起看看MMU是如何搞定地址轉換的。

4.1 MMU和Page Table

每個進程都會有自己的頁表Page Table，頁表存儲了進程中虛擬地址到物理地址的映射關系，所以就相當于一張地圖，MMU收到CPU的虛擬地址之后開始查詢頁表，確定是否存在映射以及讀寫權限是否正常，如圖：

對于4GB的虛擬地址且大小為4KB頁，一級頁表將有2^20個表項，頁表占有連續(xù)內存并且存儲空間大，多級頁表可以有效降低頁表的存儲空間以及內存連續(xù)性要求，但是多級頁表同時也帶來了查詢效率問題。

我們以2級頁表為例，MMU要先進行兩次頁表查詢確定物理地址，在確認了權限等問題后，MMU再將這個物理地址發(fā)送到總線，內存收到之后開始讀取對應地址的數據并返回。

MMU在2級頁表的情況下進行了2次檢索和1次讀寫，那么當頁表變?yōu)镹級時，就變成了N次檢索+1次讀寫。

可見，頁表級數越多查詢的步驟越多，對于CPU來說等待時間越長，效率越低，這個問題還需要優(yōu)化才行。

>> 本段小結 敲黑板 劃重點 <<
1.頁表存在于進程的內存之中，MMU收到虛擬地址之后查詢Page Table來獲取物理地址。

2.單級頁表對連續(xù)內存要求高，于是引入了多級頁表，但是多級頁表也是一把雙刃劍，在減少連續(xù)存儲要求且減少存儲空間的同時降低了查詢效率。

4.2 MMU和TLB的故事

MMU和TLB的故事就這樣開始了...

CPU覺得MMU干活雖然賣力氣，但是效率有點低，不太想繼續(xù)外包給它了，這一下子把MMU急壞了。

MMU于是找來了一些精通統(tǒng)計的朋友，經過一番研究之后發(fā)現CPU用的數據經常是一小搓，但是每次MMU都還要重復之前的步驟來檢索，害，就知道埋頭干活了，也得講究方式方法呀！

找到瓶頸之后，MMU引入了新武器，江湖人稱快表的TLB，別看TLB容量小，但是正式上崗之后干活還真是不含糊。

當CPU給MMU傳新虛擬地址之后，MMU先去問TLB那邊有沒有，如果有就直接拿到物理地址發(fā)到總線給內存，齊活。

TLB容量比較小，難免發(fā)生Cache Miss，這時候MMU還有保底的老武器頁表 Page Table，在頁表中找到之后MMU除了把地址發(fā)到總線傳給內存，還把這條映射關系給到TLB，讓它記錄一下刷新緩存。

TLB容量不滿的時候就直接把新記錄存儲了，當滿了的時候就開啟了淘汰大法把舊記錄清除掉，來保存新記錄，彷佛完美解決了問題。

在TLB和Page Table加持之下，CPU感覺最近MMU比較給力了，就問MMU怎么做到的？MMU就一五一十告訴了CPU。

CPU說是個不錯的路子，隨后說出了自己的建議：TLB還是有點小，緩存不命中也是經常發(fā)生的，要不要搞個大的，這樣存儲更多訪問更快？

MMU一臉苦笑說道大哥TLB很貴的，要不你給漲點外包費？話音未落，CPU就說漲工資是不可能了，這輩子都不可能了。