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 拷貝的優化。這種方法延續了以往那種傳統的通信方式，但更靈活。