4.3.2. 影響 TLB 效能

有幾個影響 TLB 效能的因素。第一個是分頁的大小。顯然地,分頁越大、會被塞進去的指令或資料物件也越多。所以一個比較大的快取大小減少了所需位址轉譯的整體數量,代表 TLB 快取中需要更少的項目。大部分架構現今允許使用多種不同的分頁大小;有些大小能夠並存地使用。舉例來說,x86/x86-64 處理器擁有尋常的 4kB 分頁大小,但它們也分別能夠使用 4MB 與 2MB 的分頁。IA-64 與 PowerPC 允許像是 64kB 的大小作為基礎分頁大小。

不過,大分頁尺寸的使用也隨之帶來了一些問題。為了大分頁而使用的記憶體區域在實體記憶體中必須是連續的。若是實體記憶體管理的單位大小被提高到虛擬記憶體分頁的大小,浪費的記憶體總量就會增加。各種記憶體操作(像是載入可執行程式)需要對齊到分頁邊界。這表示,平均而言,在每次映射的實體記憶體中,每次映射浪費了一半的分頁大小。這種浪費能夠輕易地累加;這因此對實體記憶體分配的合理單位大小加了個上限。

將單位大小提升到 2MB,以容納 x86-64 上的大分頁無疑並不實際。這個大小太大了。但這又意味著每個大分頁必須由多個較小的分頁所構成。而且這些小分頁在實體記憶體中必須是連續的。以 4kB 的單位分頁大小分配 2MB 的連續實體記憶體具有挑戰性。這需要尋找一個有著 512 個連續分頁的空閒區域。在系統執行一段時間、並且實體記憶體變得片段之後,這可能極端困難(或者不可能)。

因此在 Linux 上,有必要在系統啟動的時候使用特殊的 hugetlbfs 檔案系統來分配這些大分頁。一個固定數量的實體分頁會被保留來專門作為大虛擬分頁來使用。這綁住了可能不會一直用到的資源。這也是個有限的池(pool);增加它通常代表著重新啟動系統。儘管如此,在效能貴重、資源充足、且麻煩的設置不是個大阻礙的情況下,龐大的分頁便為大勢所趨。資料庫伺服器就是個例子。

$ eu-readelf -l /bin/ls
Program Headers:
  Type   Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
...
  LOAD   0x000000 0x0000000000400000 0x0000000000400000 0x0132ac 0x0132ac R E 0x200000
  LOAD   0x0132b0 0x00000000006132b0 0x00000000006132b0 0x001a71 0x001a71 RW  0x200000
...
圖 4.3:ELF 程式標頭指示了對齊需求

提高最小的虛擬分頁大小(對比於可選的大分頁)也有它的問題。記憶體映射操作(例如,載入應用程式)必須遵循這些分頁大小。不可能有更小的映射。一個可執行程式不同部分的位置––對大多架構而言––有個固定的關係。若是分頁大小增加到超過在可執行程式或者 DSO 創建時所考慮的大小時,就無法執行載入操作。將這個限制記在心上是很重要的。圖 4.3 顯示了能夠如何決定一個 ELF 二進位資料(binary)的對齊需求的。它被編碼在 ELF 的程式標頭(header)。在這個例子中,一個 x86-64 的二進位資料,值為 20000016=2,097,152=2MB 200000_{16} = 2,097,152 = \text{2MB} ,與處理器所支援的最大分頁大小相符。

使用較大的分頁大小有個次要的影響:分頁表樹的層級數量會被減低。由於對應到分頁偏移量的虛擬位址部分增加了,就沒有剩下那麼多需要透過分頁目錄處理的位元了。這表示,在一次 TLB 錯失的情況下,必須完成的工作總量減少了。

除了使用大分頁尺寸外,也可能藉由將同時用到的資料搬移到較少的分頁上,以減少所需的 TLB 項目數量。這類似於我們先前討論的針對快取使用的一些最佳化。 Only now the alignment required is large. 考慮到 TLB 項目的數量非常少,這會是個重要的最佳化。

results matching ""

    No results matching ""