各位老鐵,你們好!面試
上週大白有事停更1次,最近在想如何讓你們在10分鐘中有所收穫,因而準備搞一個"什麼是xxx"系列,寫一些精悍的知識點。緩存
先拋一道阿里面試題給你們熱熱身,引出今天的主角-缺頁異常Page Fault。服務器
談談對缺頁異常Page Fault的理解。app
話很少說,集合上車。
ide
以32位的Linux系統爲例,每一個進程獨立擁有4GB的虛擬地址空間,根據局部性原理沒有必要也不可能爲每一個進程分配4GB的物理地址空間。函數
64位系統也是同樣的道理,只不過空間尋址範圍大了不少不少倍,進程的虛擬地址空間會分爲幾個部分:性能
實際上只有程序運行時用到了纔去內存中尋找虛擬地址對應的頁幀,找不到纔可能進行分配,這就是內存的惰性(延時)分配機制。學習
對於一個運行中的進程來講,不是全部的虛擬地址在物理內存中都有對應的頁,如圖展現了部分虛擬地址存在對應物理頁的狀況:優化
虛擬地址空間根據固定大小通常是4KB進行劃分,物理內存能夠設置不一樣的頁面大小,一般物理頁大小和虛擬頁大小是同樣的,本文按照物理頁4KB大小展開。ui
通過前面的分析,咱們將面臨一個問題:如何將虛擬地址準確快速地映射到物理頁呢?
>>>高能預警 敲黑板 本段小結<<<
1. Linux的虛擬地址空間就是空頭支票,看着很大可是實際對應的物理空間只有不多的一部分。2.內存的惰性分配是個有效的機制,能夠保證內存利用率和服務器利用率,是資源合理配置的方法。
3.大量的虛擬地址到物理地址的快速準確地查詢轉換是一個難題。
CPU並不直接和物理內存打交道,而是把地址轉換的活外包給了MMU,MMU是一種硬件電路,其速度很快,主要工做是進行內存管理,地址轉換隻是它承接的業務之一。
一塊兒看看MMU是如何搞定地址轉換的。
每一個進程都會有本身的頁表Page Table,頁表存儲了進程中虛擬地址到物理地址的映射關係,因此就至關於一張地圖,MMU收到CPU的虛擬地址以後開始查詢頁表,肯定是否存在映射以及讀寫權限是否正常,如圖:
對於4GB的虛擬地址且大小爲4KB頁,一級頁表將有2^20個表項,頁表佔有連續內存而且存儲空間大,多級頁表能夠有效下降頁表的存儲空間以及內存連續性要求,可是多級頁表同時也帶來了查詢效率問題。
咱們以2級頁表爲例,MMU要先進行兩次頁表查詢肯定物理地址,在確認了權限等問題後,MMU再將這個物理地址發送到總線,內存收到以後開始讀取對應地址的數據並返回。
MMU在2級頁表的狀況下進行了2次檢索和1次讀寫,那麼當頁表變爲N級時,就變成了N次檢索+1次讀寫。
可見,頁表級數越多查詢的步驟越多,對於CPU來講等待時間越長,效率越低,這個問題還須要優化才行。
>> 本段小結 敲黑板 劃重點 <<
1.頁表存在於進程的內存之中,MMU收到虛擬地址以後查詢Page Table來獲取物理地址。2.單級頁表對連續內存要求高,因而引入了多級頁表,可是多級頁表也是一把雙刃劍,在減小連續存儲要求且減小存儲空間的同時下降了查詢效率。
MMU和TLB的故事就這樣開始了...
CPU以爲MMU幹活雖然賣力氣,可是效率有點低,不太想繼續外包給它了,這一會兒把MMU急壞了。
MMU因而找來了一些精通統計的朋友,通過一番研究以後發現CPU用的數據常常是一小搓,可是每次MMU都還要重複以前的步驟來檢索,害,就知道埋頭幹活了,也得講究方式方法呀!
找到瓶頸以後,MMU引入了新武器,江湖人稱快表的TLB,別看TLB容量小,可是正式上崗以後幹活還真是不含糊。
當CPU給MMU傳新虛擬地址以後,MMU先去問TLB那邊有沒有,若是有就直接拿到物理地址發到總線給內存,齊活。
TLB容量比較小,不免發生Cache Miss,這時候MMU還有保底的老武器頁表 Page Table,在頁表中找到以後MMU除了把地址發到總線傳給內存,還把這條映射關係給到TLB,讓它記錄一下刷新緩存。
TLB容量不滿的時候就直接把新記錄存儲了,當滿了的時候就開啓了淘汰大法把舊記錄清除掉,來保存新記錄,似乎完美解決了問題。
在TLB和Page Table加持之下,CPU感受最近MMU比較給力了,就問MMU怎麼作到的?MMU就一五一十告訴了CPU。
CPU說是個不錯的路子,隨後說出了本身的建議:TLB仍是有點小,緩存不命中也是常常發生的,要不要搞個大的,這樣存儲更多訪問更快?
MMU一臉苦笑說道大哥TLB很貴的,要不你給漲點外包費?話音未落,CPU就說漲工資是不可能了,這輩子都不可能了。
>>>高能預警 敲黑板 本段小結<<<
1. CPU要根據用戶進程提供的虛擬地址來獲取真實數據,可是它並不本身作而是交給了MMU。2. MMU也是個聰明的傢伙,集成了TLB來存儲CPU最近經常使用的頁表項來加速尋址,TLB找不到再去全量頁表尋址,能夠認爲TLB是MMU的緩存。
3. TLB的容量畢竟有限,爲此必須依靠Page Table一塊兒完成TLB Miss狀況的查詢,而且更新到TLB創建新映射關係。
設想CPU給MMU的虛擬地址在TLB和Page Table都沒有找到對應的物理頁幀或者權限不對,該怎麼辦呢?
沒錯,這就是缺頁異常Page Fault,它是一個由硬件中斷觸發的能夠由軟件邏輯糾正的錯誤。
假如目標內存頁在物理內存中沒有對應的頁幀或者存在但無對應權限,CPU 就沒法獲取數據,這種狀況下CPU就會報告一個缺頁錯誤。
因爲CPU沒有數據就沒法進行計算,CPU罷工了用戶進程也就出現了缺頁中斷,進程會從用戶態切換到內核態,並將缺頁中斷交給內核的 Page Fault Handler 處理。
缺頁中斷會交給PageFaultHandler處理,其根據缺頁中斷的不一樣類型會進行不一樣的處理:
不一樣類型的Page Fault出現的緣由也不同,常見的幾種緣由包括:
>>> 敲黑板 劃重點 本段小結:<<<
觸發Page Fault的緣由可能有不少,歸根到底也只有幾種大類:1. 如使用共享內存區域,沒有存儲VA->PA的映射可是存在物理頁幀的軟缺頁錯誤,在Page Table/TLB中創建映射關係便可。
2. 訪問的地址在物理內存中確實不存在,須要從磁盤/swap分區讀入才能使用,這種性能影響會比較大,由於磁盤太慢了,儘可能使用高性能的SSD來下降延時。
3. 訪問的地址內存非法,缺頁錯誤會升級觸發SIGSEGV信號結束進程,這種屬於能夠致使進程掛掉的一種缺頁錯誤。
本文粗淺地和你們一塊兒學習了Page Fault的相關知識點,包括Linux虛擬地址和物理地址的關係、CPU獲取內存數據的過程、MMU和TLB&頁表的協同配合、缺頁異常產生的緣由和分類處理。
本文並無對MMU的內部機制、內核態&用戶態缺頁異常、缺頁異常處理函數等內容進行展開,主要是由於這部份內容相對晦澀,還得靠本身深刻研究。
本文旨在把火點燃而不是把桶填滿,對於文中相關知識點,歡迎交流溝通學習。
感謝各位老鐵的傾情安排,下期再見!