DMA 與零拷貝技術

原文鏈接：DMA 與零拷貝技術

注意事項：除了 Direct I/O，與磁盤相關的檔案讀寫操作都有使用到 page cache 技術，

1. 資料的四次拷貝與四次背景關系切換

很多應用程式在面臨客戶端請求時，可以等價為進行如下的系統呼叫：

1. File.read(file, buf, len);
2. Socket.send(socket, buf, len);

例如訊息中間件 Kafka 就是這個應用場景，從磁盤中讀取一批訊息后原封不動地寫入網卡（NIC，Network interface controller）進行發送，

在沒有任何優化技術使用的背景下，作業系統為此會進行 4 次資料拷貝，以及 4 次背景關系切換，如下圖所示：

如果沒有優化，讀取磁盤資料，再通過網卡傳輸的場景性能比較差：

4 次 copy：

• 物理設備 <-> 記憶體：

  • CPU 負責將資料從磁盤搬運到內核空間的 Page Cache 中；
  • CPU 負責將資料從內核空間的 Socket 緩沖區搬運到的網路中；

• 記憶體內部拷貝：

  • CPU 負責將資料從內核空間的 Page Cache 搬運到用戶空間的緩沖區；
  • CPU 負責將資料從用戶空間的緩沖區搬運到內核空間的 Socket 緩沖區中；

4 次背景關系切換：

1. read 系統呼叫時：用戶態切換到內核態；
2. read 系統呼叫完畢：內核態切換回用戶態；
3. write 系統呼叫時：用戶態切換到內核態；
4. write 系統呼叫完畢：內核態切換回用戶態；

我們不免發出抱怨：

1. CPU 全程負責記憶體內部的資料拷貝還可以接受，因為記憶體的資料拷貝效率還行（不過還是比 CPU 慢很多），但是如果要 CPU 全程負責記憶體與磁盤、記憶體與網卡的資料拷貝，這將難以接受，因為磁盤、網卡的 I/O 速度遠小于記憶體；
2. 4 次 copy 太多了，4 次背景關系切換也太頻繁了；

2. DMA 參與下的資料四次拷貝

DMA 技術很容易理解，本質上，DMA 技術就是我們在主板上放一塊獨立的芯片，在進行記憶體和 I/O 設備的資料傳輸的時候，我們不再通過 CPU 來控制資料傳輸，而直接通過 DMA 控制器（DMA Controller，簡稱 DMAC），這塊芯片，我們可以認為它其實就是一個協處理器（Co-Processor），

DMAC 的價值在如下情況中尤其明顯：當我們要傳輸的資料特別大、速度特別快，或者傳輸的資料特別小、速度特別慢的時候，

比如說，我們用千兆網卡或者硬碟傳輸大量資料的時候，如果都用 CPU 來搬運的話，肯定忙不過來，所以可以選擇 DMAC，而當資料傳輸很慢的時候，DMAC 可以等資料到齊了，再發送信號，給到 CPU 去處理，而不是讓 CPU 在那里忙等待，

這里面的“協”字，DMAC 是在“協助”CPU，完成對應的資料傳輸作業，在 DMAC 控制資料傳輸的程序中，DMAC 還是被 CPU 控制，只是資料的拷貝行為不再由 CPU 來完成，

原本，計算機所有組件之間的資料拷貝（流動）必須經過 CPU，以磁盤讀寫為例，如下圖所示：

現在，DMAC 代替了 CPU 負責記憶體與磁盤、記憶體與網卡之間的資料搬運，CPU 作為 DMAC 的控制者，如下圖所示：

但是 DMAC 有其局限性，DMAC 僅僅能用于設備間交換資料時進行資料拷貝，但是設備內部的資料拷貝還需要 CPU 來親力親為，例如， CPU 需要負責內核空間與用戶空間之間的資料拷貝（記憶體內部的拷貝），如下圖所示：

3. 零拷貝技術

3.1 什么是零拷貝技術？

零拷貝技術是一個思想，指的是指計算機執行操作時，CPU 不需要先將資料從某處記憶體復制到另一個特定區域，

可見，零拷貝的特點是 CPU 不全程負責記憶體中的資料寫入其他組件，CPU 僅僅起到管理的作用，但注意，零拷貝不是不進行拷貝，而是 CPU 不再全程負責資料拷貝時的搬運作業，如果資料本身不在記憶體中，那么必須先通過某種方式拷貝到記憶體中（這個程序 CPU 可以僅僅負責管理，DMAC 來負責具體資料拷貝），因為資料只有在記憶體中，才能被轉移，才能被 CPU 直接讀取計算，

零拷貝技術的具體實作方式有很多，例如：

• sendfile
• mmap
• 直接 Direct I/O
• splice

不同的零拷貝技術適用于不同的應用場景，下面依次進行 sendfile、mmap、Direct I/O 的分析，

不過，我們不妨先在這里做一個前瞻性的技術總結，

• DMA 技術：DMA 負責記憶體與其他組件之間的資料拷貝，CPU 僅需負責管理，而無需負責全程的資料拷貝；
• 使用 page cache 的 zero copy：
  • sendfile：一次代替 read/write 系統呼叫，通過使用 DMA 技術以及傳遞檔案描述符，實作了 zero copy；
  • mmap：僅代替 read 系統呼叫，將內核空間地址映射為用戶空間地址，write 操作直接作用于內核空間，通過 DMA 技術以及地址映射技術，用戶空間與內核空間無須資料拷貝，實作了 zero copy；
• 不使用 page cache 的 Direct I/O：讀寫操作直接在磁盤上進行，不使用 page cache 機制，通常結合用戶空間的用戶快取使用，通過 DMA 技術直接與磁盤/網卡進行資料互動，實作了 zero copy；

3.2 sendfile

snedfile 的應用場景是：用戶從磁盤讀取一些檔案資料后不需要經過任何計算與處理就通過網路傳輸出去，此場景的典型應用是訊息佇列，

在傳統 I/O 下，正如第一節所示，上述應用場景的一次資料傳輸需要四次 CPU 全權負責的拷貝與四次背景關系切換，正如本文第一節所述，

sendfile 主要使用到了兩個技術：

1. DMA 技術；
2. 傳遞檔案描述符代替資料拷貝；

利用 DMA 技術，sendfile 依賴于 DMA 技術，將四次 CPU 全程負責的拷貝與四次背景關系切換減少到兩次，如下圖所示，DMA 負責磁盤到內核空間中的 Page cache（read buffer）的資料拷貝以及從內核空間中的 socket buffer 到網卡的資料拷貝，

傳遞檔案描述符代替資料拷貝，傳遞檔案描述可以代替資料拷貝，這是由于兩個原因：

• page cache 以及 socket buffer 都在內核空間中；
• 資料在傳輸中沒有被更新；
  

只有網卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技術才可以通過傳遞檔案描述符的方式避免內核空間內的一次 CPU 拷貝，這意味著此優化取決于 Linux 系統的物理網卡是否支持（Linux 在內核 2.4 版本里引入了 DMA 的 scatter/gather – 分散/收集功能，只要確保 Linux 版本高于 2.4 即可），

3.3 mmap

MMAP

3.4 Direct I/O

Direct I/O 即直接 I/O，其名字中的“直接”二字用于區分使用 page cache 機制的快取 I/O，

• 快取檔案 I/O：用戶空間要讀寫一個檔案并不直接與磁盤互動，而是中間夾了一層快取，即 page cache；
• 直接檔案 I/O：用戶空間讀取的檔案直接與磁盤互動，沒有中間 page cache 層；

“直接”在這里還有另一層語意：其他所有技術中，資料至少需要在內核空間存盤一份，但是在 Direct I/O 技術中，資料直接存盤在用戶空間中，繞過了內核，

Direct I/O 模式如下圖所示：

Direct I/O 的讀寫非常有特點：

• Write 操作：由于其不使用 page cache，所以其進行寫檔案，如果回傳成功，資料就真的落盤了（不考慮磁盤自帶的快取）；
• Read 操作：由于其不使用 page cache，每次讀操作是真的從磁盤中讀取，不會從檔案系統的快取中讀取，

事實上，即使 Direct I/O 還是可能需要使用作業系統的 fsync 系統呼叫，為什么？

這是因為雖然檔案的資料本身沒有使用任何快取，但是檔案的元資料仍然需要快取，包括 VFS 中的 inode cache 和 dentry cache 等，

在部分作業系統中，在 Direct I/O 模式下進行 write 系統呼叫能夠確保檔案資料落盤，但是檔案元資料不一定落盤，如果在此類作業系統上，那么還需要執行一次 fsync 系統呼叫確保檔案元資料也落盤，否則，可能會導致檔案例外、元資料確實等情況，MySQL 的 O_DIRECT 與 O_DIRECT_NO_FSYNC 配置是一個具體案例，

Direct I/O 的缺點：

1. 由于設備之間的資料傳輸是通過 DMA 完成的，因此用戶空間的資料緩沖區記憶體頁必須進行 page pinning（頁鎖定），這是為了防止其物理頁框地址被交換到磁盤或者被移動到新的地址而導致 DMA 去拷貝資料的時候在指定的地址找不到記憶體頁從而引發缺頁錯誤，而頁鎖定的開銷并不比 CPU 拷貝小，所以為了避免頻繁的頁鎖定系統呼叫，應用程式必須分配和注冊一個持久的記憶體池，用于資料緩沖，

2. 如果訪問的資料不在應用程式快取中，那么每次資料都會直接從磁盤進行加載，這種直接加載會非常緩慢，

3. 在應用層引入直接 I/O 需要應用層自己管理，這帶來了額外的系統復雜性；

誰會使用 Direct I/O？自快取應用程式（ self-caching applications）可以選擇使用 Direct I/O，對于某些應用程式來說，它會有它自己的資料快取機制，比如，它會將資料快取在應用程式地址空間，這類應用程式完全不需要使用作業系統內核中的高速緩沖存盤器，這類應用程式就被稱作是自快取應用程式（ self-caching applications ），

例如，應用內部維護一個快取空間，當有讀操作時，首先讀取應用層的快取資料，如果沒有，那么就通過 Direct I/O 直接通過磁盤 I/O 來讀取資料，快取仍然在應用，只不過應用覺得自己實作一個快取比作業系統的快取更高效，

資料庫管理系統是這類應用程式的一個代表，自快取應用程式傾向于使用資料的邏輯表達方式，而非物理表達方式；當系統記憶體較低的時候，自快取應用程式會讓這種資料的邏輯快取被換出，而并非是磁盤上實際的資料被換出，自快取應用程式對要操作的資料的語意了如指掌，所以它可以采用更加高效的快取替換演算法，自快取應用程式有可能會在多臺主機之間共享一塊記憶體，那么自快取應用程式就需要提供一種能夠有效地將用戶地址空間的快取資料置為無效的機制，從而確保應用程式地址空間快取資料的一致性，

page cache 是 Linux 為所有應用提供的快取機制，但是資料庫應用太特殊了，page cache 影響了資料對特性的追求，

4. 典型案例

4.1 Kakfa

Kafka 作為一個訊息佇列，涉及到磁盤 I/O 主要有兩個操作：

• Provider 向 Kakfa 發送訊息，Kakfa 負責將訊息以日志的方式持久化落盤；
• Consumer 向 Kakfa 進行拉取訊息，Kafka 負責從磁盤中讀取一批日志訊息，然后再通過網卡發送；

Kakfa 服務端接收 Provider 的訊息并持久化的場景下使用 mmap 機制，能夠基于順序磁盤 I/O 提供高效的持久化能力，使用的 Java 類為 java.nio.MappedByteBuffer，

Kakfa 服務端向 Consumer 發送訊息的場景下使用 sendfile 機制，這種機制主要兩個好處：

• sendfile 避免了內核空間到用戶空間的 CPU 全程負責的資料移動；
• sendfile 基于 Page Cache 實作，因此如果有多個 Consumer 在同時消費一個主題的訊息，那么由于訊息一直在 page cache 中進行了快取，因此只需一次磁盤 I/O，就可以服務于多個 Consumer；

使用 mmap 來對接收到的資料進行持久化，使用 sendfile 從持久化介質中讀取資料然后對外發送是一對常用的組合，但是注意，你無法利用 sendfile 來持久化資料，利用 mmap 來實作 CPU 全程不參與資料搬運的資料拷貝，

4.2 MySQL

MySQL 的具體實作比 Kakfa 復雜很多，這是因為支持 SQL 查詢的資料庫本身比訊息佇列對復雜很多，

MySQL 的零拷貝技術

5. 總結

DMA 技術使得記憶體與其他組件，例如磁盤、網卡進行資料拷貝時，CPU 僅僅需要發出控制信號，而拷貝資料的程序則由 DMAC 負責完成，

Linux 的零拷貝技術有多種實作策略，但根據策略可以分為如下幾種型別：

• 減少甚至避免用戶空間和內核空間之間的資料拷貝：在一些場景下，用戶行程在資料傳輸程序中并不需要對資料進行訪問和處理，那么資料在 Linux 的 Page Cache 和用戶行程的緩沖區之間的傳輸就完全可以避免，讓資料拷貝完全在內核里進行，甚至可以通過更巧妙的方式避免在內核里的資料拷貝，這一類實作一般是是通過增加新的系統呼叫來完成的，比如 Linux 中的 mmap()，sendfile() 以及 splice() 等，
• 繞過內核的直接 I/O：允許在用戶態行程繞過內核直接和硬體進行資料傳輸，內核在傳輸程序中只負責一些管理和輔助的作業，這種方式其實和第一種有點類似，也是試圖避免用戶空間和內核空間之間的資料傳輸，只是第一種方式是把資料傳輸程序放在內核態完成，而這種方式則是直接繞過內核和硬體通信，效果類似但原理完全不同，
• 內核緩沖區和用戶緩沖區之間的傳輸優化：這種方式側重于在用戶行程的緩沖區和作業系統的頁快取之間的 CPU 拷貝的優化，這種方法延續了以往那種傳統的通信方式，但更靈活，

標籤：其他

上一篇：YAML 有漏洞被棄用？網友：YAML 不背鍋！

下一篇：單例設計模式