Translation Look-aside Buffer(TLB)

這一切看似美好的機制下藏有一些缺陷，想像一個Process區要去存取一個記憶體位置的值，需要先撈出page table，找到page內對應的值，再去存取實際的記憶體位置，以這樣的方法光是一個普通的操作就需要兩次的記憶體存取，第一次去讀page table，第二才是去讀真實要的資料。直接影響了一倍的效能，很有可能會讓系統的效能卡在記憶體的操作上。

解決這個問題的方法是透過硬體設備 - Translation Look-aside Buffer(TLB)，不論是在搜尋還是存取都非常快速的cache裝置，使用的概念非常簡單，將查過的資料都先儲存在TLB之上(某個page對應到哪個frame)，當CPU要去存取記憶體之前會先透過TLB查詢，如果TLB上已經有快取就直接拿到了page跟frame的關聯性，省去一次讀取記憶體的時間。

跟所有的儲存設備一樣，越快的設備容量就越小、造價也越貴，因此TLB裡面能存的快取空間也不會太大，且TLB是與所有的Process一起共用的，因此在context switch之後，需要讀取的page table換了之後cache當然也沒用了，所以TLB基本上都會清空。

page table structure

另外一個潛藏的危機是因為現現代的硬體設備越來越好，程式越來越大，page table的長度也跟著變得非常大，若用一個陣列的方式去儲存page table，則會需要很多連續又大的空間(有多少個process就有多少個)，為了解決這個問題，就針對page table的結構下功夫做變化。

• Hierarchical Paging: 把一長串的序列拆解成樹狀的階層，概念和結構會長得非常像在C++裡動態配置多重陣列的結果，舉例來說有100個長度要切，能夠先切一個長度是5的裡面存著一個位置，指到的是一個長度為20的記憶體位置，原先需要連續長度100的記憶體空間，則能夠變成只需要5個連續長度20的記憶體空間。壞處就是每多一個階層，存取memory的次數就要再+1，影響效能。
• Hashed Page Tables: 使用資料結構(hash)去儲存整個page table，透過Buckets的設計能夠分散資料，也可以很快的透過hash的方法去找到在哪個buecket底下。且如果buecket的數量決定的好，可以在很少次memory的存取就找到。
• Inverted Page Tables: 不使用page當作table的索引，而是使用frame number與Process ID。因為frame是從physical memory切出來的，physical memory是取決於硬體，基本上算是固定的，所以frame table可以事先就被建好且不會再被改變。壞處就是很難去search by page，以及process的sharing。