第二十天 Memory Management(記憶體管理)--下之二

今天來結束這章節吧！

昨天我們有提到page table，今天來說說如何實作他吧！
Page table是存放在記憶體中，作業系統運用page-table base register(PTBR)記錄起始位置跟page-table length register(PTLR)記錄page table的大小。這有個缺點：速度慢，就是因為他必須存取記憶體兩次，一次是page table，一次是要找的data。幸好這個缺點有個方法可以解決，用Translation Look-aside Buffers(TLBs)，他就類似我們之前所提的快取(cache)。

Translation Look-aside Buffers(TLBs)：保存部分常用的page table
應用：

1. 先到TLBs內看有沒有對應的page number
2. 有 -> 輸出frame起始位置，記憶體只存取一次
3. 沒有 -> 到記憶體取page table再查，記憶體存取兩次
   以下有參考圖：
   
   Effective access time：
   運用TLBs通常能節省10%的時間，有一個公式能算使用TLBs的時間，我們來用公式算算，下面是他的公式：
   ε代表TLBs找的時間
   α代表在TLBs內找到的機率
   
   前面的(1+ε)，1代表存取記憶體一次所要的時間(後面的2以此類推)
   以下我們舉個例子：
   假設α為80%，ε為20ns，100ns是記憶體內存取時間
   他的EAT=0.8 x (100+20)+0.2 x (100+100+20)=140ns

他也有保護機制，每個frame都有protection bit，看是唯獨或是讀寫都可以。如果protection bit是valid，代表可執行，相對的page在process的logical address; 如果是invalid，代表不可行，相對的page不在process的logical address。下方有參考圖：

而page是可以共享的，有些code是process間共用的，就可以把它集中到某幾頁page上，向下方參考圖的page 3、4、6就是shared page：

Page table的架構有三種：

1. Hierarchical page table(層次式分頁表)：
   將logical address space分成很多page table，形成page of page table，這個方法只抓需要的page table進入記憶體中。以下是兩層式的page table：
   

2. Hashed page table(雜湊分頁表)：
   將logical address的page透過雜湊運算，取得hash table內的bucket address。每個bucket，都用link list來連接擁有相同hashing number的page number跟frame number。後來再去link list中搜尋符合的page number，取得frame number，在與offset相加取得physical address。

   Hashed table內的element有：

   1. 虛擬的page number(bucket address)
   2. Mapped page frame的值
   3. 到下一個element的指標
      

3. Inverted page table(反轉分頁表)：
   他是以physical address為對象，建立一個page table給所有process(有m個frame，就有m個table entry)，每個entry都會紀錄被哪個process的page運用，所以裡面記錄著process id跟page number。
   

這章就說到這啦！