Merge pull request #8 from st10740/master

Proofread

commodity-hardware-today/ram-types/dynamic-ram.md

@@ -7,7 +7,7 @@
   <figcaption>圖 2.5：1-T 動態 RAM</figcaption>
 </figure>
 
-一個動態 RAM 的記憶單元在電容 $$ \mathbf{C} $$ 中保存其狀態。電晶體 $$ \mathbf{M} $$ 用以控制狀態的存取。為了讀取記憶單元的狀態，要提高存取線路 $$ \mathbf{AL} $$ 的電位；這要不使得電流流經資料線路（data line） $$ \mathbf{DL} $$、要不沒有，取決於電容中的電量。要寫到記憶單元中，則要適當地設置資料線路 $$ \mathbf{DL} $$，然後提高 $$ \mathbf{AL} $$ 的電位一段足以讓電容充電或放電的時間。
+一個動態 RAM 的記憶單元在電容 $$ \mathbf{C} $$ 中保存其狀態。電晶體 $$ \mathbf{M} $$ 用以控制狀態的存取。為了讀取記憶單元的狀態，要提高存取線路 $$ \mathbf{AL} $$ 的電位；這要不使得電流流經資料線路（data line） $$ \mathbf{DL} $$、要不沒有，取決於電容中的電量。要寫到記憶單元中，則要適當地設置資料線路 $$ \mathbf{DL} $$，然後將 $$ \mathbf{AL} $$ 的電位提高至足夠長的時間，以讓電容充電或放電。
 
 動態 RAM 有許多設計上的難題。使用電容意味著讀取記憶單元時會對電容放電。這件事無法不斷重複，必須在某個時間點上對電容重新充電。更糟的是，為了容納大量的記憶單元（晶片有著 10<sup>9</sup> 或者更多的記憶單元在現今是很普遍的），電容的電量必須很低（在飛〔femto，10<sup>-15</sup>〕法拉範圍內或者更小）。完全充電後的電容容納了數萬個電子。儘管電容的電阻很高（幾兆歐姆），耗盡電容仍舊只需要很短的時間。這個問題被稱為「漏電（leakage）」。
 

cpu-caches.md

@@ -12,7 +12,7 @@
 
 一個簡單的計算就能看出快取在理論上有多有效。假設存取主記憶體花費 200 個週期，而存取快取記憶體花費 15 個週期。接著，程式使用 100 個資料元素各 100 次，若是沒有快取，將會在記憶體操作上耗費 2,000,000 個循環，而若是所有資料都被快取過，只要 168,500 個週期。提升了 91.5%。
 
-用作快取的 SRAM 容量比起主記憶體小了好幾倍。根據作者使用具有 CPU 快取的工作站（workstation）的經驗，快取的容量總是主記憶體容量的 1/1000 左右（現今：4MB 快取與 4GB 主記憶體）。單是如此並不會形成問題。假如工作集（正在處理的資料集）的容量小於快取，這無傷大雅。但是電腦沒理由不擁有大量的主記憶體。工作集必定會比快取還大。尤其是執行多個行程的系統，其工作集的容量為所有個別的處理器與系統核心的容量總和。
+用作快取的 SRAM 容量比起主記憶體小了好幾倍。根據作者使用具有 CPU 快取的工作站（workstation）的經驗，快取的容量總是主記憶體容量的 1/1000 左右（現今：4MB 快取與 4GB 主記憶體）。單是如此並不會形成問題。假如工作集（正在處理的資料集）的容量小於快取，這無傷大雅。但是電腦沒理由不擁有大量的主記憶體。工作集必定會比快取還大。尤其是執行多個行程的系統，其工作集的容量為所有個別的行程與系統核心的容量總和。
 
 應對快取的容量限制所需要的是，一組能在任何給定的時間點決定什麼該快取的策略。由於並非所有工作集的資料都會*正好*在相同的時間點使用，所以我們可以使用一些技術來暫時地將一些快取中的資料替換成別的資料。而且這也許能在真的需要資料之前就搞定。這種預取會去除一些存取主記憶體的成本，因為對程式的執行而言，這是非同步進行的。這所有的技術都能用來讓快取看起來比實際上還大。我們將會在 3.3 節討論它們。一旦探究完這全部的技術，協助處理器就是程式開發者的責任了。這些作法將會在第六節中討論。
 

cpu-caches/cpu-cache-implementation-details/measurements-of-cache-effects.md

@@ -42,8 +42,7 @@ struct l {
 
 我們能夠在預取的時候 –– 至少間接地 –– 觀察處理器。在圖 3.11 中，我們看到的是相同工作集容量的時間，但這次我們看到的是不同 `l` 結構容量的曲線。這表示在串列中有比較少、但比較大的元素。不同容量有著令（仍然連續的）串列中的 `n` 元素之間的距離成長的影響。在圖中的四種情況，距離分別為 0、56、120、248 位元組。
 
-在底部我們可以看到圖 3.10 的線，但這時它看起來差不多像是條平坦的線。其它情況的時間要糟得多了。我們也能在這張圖中看到三個不同的水平，我們也看到在工作集容量很小的情況下有著很大的誤差（再次忽略它們）。只要僅有 L1d 牽涉其中，這些線差不多都相互重合。
-There is no prefetching necessary so all element sizes just hit the L1d for each access.
+在底部我們可以看到圖 3.10 的線，但這時它看起來差不多像是條平坦的線。其它情況的時間要糟得多了。我們也能在這張圖中看到三個不同的水平，我們也看到在工作集容量很小的情況下有著很大的誤差（再次忽略它們）。只要僅有 L1d 牽涉其中，這些線差不多都相互重合。因為不需要預取，所以每次存取時，所有元素大小都直接命中 L1d。
 
 在 L2 快取命中的情況下，我們看到三條新的線相互重合得很好，但它們位在比較高的水平上（大約 28）。這是 L2 存取時間的水平。這表示從 L2 到 L1d 的預取基本上失效了。即使是 `NPAD`=7，我們在迴圈的每一次疊代都需要一個新的快取行；以 `NPAD`=0 而言，在需要下一個快取行之前，迴圈得疊代八次。預取邏輯無法每個週期都載入一個新的快取行。因此，我們看到的便是在每次疊代時，從 L2 載入的延誤。
 

virtual-memory/impact-of-virtualization.md

@@ -7,7 +7,7 @@
   <figcaption>圖 4.4：Xen 虛擬化模型</figcaption>
 </figure>
 
-在 Xen 的情況下（見圖 4.4），Xen VMM 即是這個軟體。不過 VMM 本身並不實作太多其它的硬體控制。不若在其它較早期的系統（以及首次釋出的 Xen VMM）上的 VMM，除了記憶體與處理器之外的硬體是由具有特權的 Dom0 域所控制的。目前，這基本上是與沒有特權的 DomU 系統核心相同的系統核心，而且 –– 就所關心的記憶體管理而言 –– 它們沒什麼區別。重要的是，VMM 將實體記憶體分發給了 Dom0 與 DomU 系統核心，其因而實作了普通的記憶體管理，就好像它們是直接執行在一個處理器上一樣。
+在 Xen 的情況下（見圖 4.4），Xen VMM 即是這個軟體。不過 VMM 本身並不實作太多其它的硬體控制。不若在其它較早期的系統（以及首次釋出的 Xen VMM）上的 VMM，除了記憶體與處理器之外的硬體是由具有特權的 Dom0 域所控制的。目前，這跟運作於非特權模式的 DomU 具備相同的系統核心，而且 –– 就所關心的記憶體管理而言 –– 它們沒什麼區別。重要的是，VMM 將實體記憶體分發給了 Dom0 與 DomU 系統核心，其因而實作了普通的記憶體管理，就好像它們是直接執行在一個處理器上一樣。
 
 為了實現完成虛擬化所需的域的分離，Dom0 與 DomU 系統核心中的記憶體處理並不具有無限制的實體記憶體存取。VMM 不是藉由分發獨立的實體分頁、並讓客戶端作業系統處理定址的方式來分發記憶體；這不會提供任何針對有缺陷或者流氓客戶域的防範。取而代之地，VMM 會為每個客戶域建立它自己擁有的分頁表樹，並使用這些資料結構來分發記憶體。好處是能夠控制對分頁表樹的管理資訊的存取。若是程式沒有合適的權限，它就什麼也無法做。
 

virtual-memory/multi-level-page-tables.md

@@ -15,7 +15,7 @@
 
 每個在系統中執行的行程會需要它自己的分頁表樹。部分地共享樹是可能的，但不如說這是個例外狀況。因此，如果分頁表樹所需的記憶體盡可能地小的話，對效能與延展性而言都是有益的。理想的情況是將用到的記憶體彼此靠近地擺在虛擬定址空間中；實際用到的實體位址則無關緊要。對一支小程式而言，僅僅使用在第二、三、四層各自的一個目錄、以及少許第一層目錄，可能還過得去。在有著 4kB 分頁以及每目錄 512 個項目的 x86-64 上，這能夠以總計 4 個目錄（每層一個）來定址 2MB。1GB 的連續記憶體能夠以一個第二到第四層目錄、以及 512 個第一層目錄來定址。
 
-不過，假設能夠連續地分配所有記憶體也太過於簡化了。為了彈性起見，一個行程的堆疊（stack）與堆積（heap）區域 –– 在大多情況下 –– 會被分配在定址空間中極為相對的兩端。這令二個區域在需要時都能盡可能地增長。這表示，最有可能是二個需要的第二層目錄，以及與此相應的、更多低層級的目錄。
+不過，假設能夠連續地分配所有記憶體也太過於簡化了。為了彈性起見，一個行程的堆疊（stack）與堆積（heap）區域 –– 在大多情況下 –– 會被分配在定址空間中極為相對的兩端。這令二個區域在需要時都能盡可能地增長。這表示，最有可能是需要兩個第二層目錄，以及與此相應的、更多低層級的目錄。
 
 但即使如此也不總是符合目前的實際狀況。為了安全考量，一個可執行程式的多個部分（程式碼、資料、堆積、堆疊、動態共享物件〔Dynamic Shared Object，DSO〕，又稱共享函式庫〔shared library〕）會被映射在隨機化的位址上 [9]。隨機化擴大了不同部份的相對位置；這暗示著，在一個行程裡使用中的不同記憶體區域會廣泛地散布在虛擬定址空間中。藉由在隨機化的位址的位元數上施加一些限制也能夠限制範圍，但這無疑 –– 在大多情況下 –– 會讓一個行程無法以僅僅一或二個第二與第三層目錄來執行。
 

virtual-memory/optimizing-page-table-access/influencing-tlb-performance.md

@@ -23,7 +23,5 @@ Program Headers:
 
 使用較大的分頁容量有個次要的影響：分頁表樹的層級數量會被減低。由於對應到分頁偏移量的虛擬位址部分增加了，就沒有剩下那麼多需要透過分頁目錄處理的位元了。這表示，在一次 TLB 錯失的情況下，必須完成的工作總量減少了。
 
-除了使用大分頁尺寸外，也可能藉由將同時用到的資料搬移到較少的分頁上，以減少所需的 TLB 項目數量。這類似於我們先前討論的針對快取使用的一些最佳化。
-Only now the alignment required is large.
-考慮到 TLB 項目的數量非常少，這會是個重要的最佳化。
+除了使用大分頁尺寸外，也可能藉由將同時用到的資料搬移到較少的分頁上，以減少所需的 TLB 項目數量。這類似於我們先前討論的針對快取使用的一些最佳化。不過現在所需的對齊更大。考慮到 TLB 項目的數量非常少，這會是個重要的最佳化。