Linux 中的零拷貝技術，第 2 部分

Linux 中的直接 I/O
如果應用程式可以直接存取網路介面儲存，那麼在應用程式訪問資料之前儲存匯流排就不需要被遍曆，資料轉送所引起的開銷將會是最小的。應用程式或者運行在使用者模式下的庫函數可以直接存取硬體裝置的儲存，作業系統核心除了進行必要的虛擬儲存配置工作之外，不參與資料轉送過程中的其它任何事情。直接 I/O 使得資料可以直接在應用程式和外圍裝置之間進行傳輸，完全不需要作業系統核心頁緩衝的支援。關於直接 I/O 技術的具體實現細節可以參看 developerWorks 上的另一篇文章”Linux 中直接 I/O 機制的介紹” ，本文不做過多描述。

圖 1. 使用直接 I/O 的資料轉送

針對資料轉送不需要經過應用程式地址空間的零拷貝技術
利用 mmap()
在 Linux 中，減少拷貝次數的一種方法是調用 mmap() 來代替調用 read，比如：

tmp_buf = mmap(file, len);  write(socket, tmp_buf, len);

首先，應用程式調用了 mmap() 之後，資料會先通過 DMA 拷貝到作業系統核心的緩衝區中去。接著，應用程式跟作業系統共用這個緩衝區，這樣，作業系統核心和應用程式儲存空間就不需要再進行任何的資料拷貝操作。應用程式調用了 write() 之後，作業系統核心將資料從原來的核心緩衝區中拷貝到與 socket 相關的核心緩衝區中。接下來，資料從核心
socket 緩衝區拷貝到協議引擎中去，這是第三次資料拷貝操作。

圖 2. 利用 mmap() 代替 read()

通過使用 mmap() 來代替 read(), 已經可以減半作業系統需要進行資料拷貝的次數。當大量資料需要傳輸的時候，這樣做就會有一個比較好的效率。但是，這種改進也是需要代價的，使用 mma()p 其實是存在潛在的問題的。當對檔案進行了記憶體映射，然後調用 write() 系統調用，如果此時其他的進程截斷了這個檔案，那麼 write() 系統調用將會被匯流排錯誤訊號 SIGBUS 中斷，因為此時正在執行的是一個錯誤的儲存訪問。這個訊號將會導致進程被殺死，解決這個問題可以通過以下這兩種方法：

1. 為 SIGBUS 安裝一個新的訊號處理器，這樣，write() 系統調用在它被中斷之前就返回已經寫入的位元組數目，errno 會被設定成 success。但是這種方法也有其缺點，它不能反映出產生這個問題的根源所在，因為 BIGBUS 訊號只是顯示某進程發生了一些很嚴重的錯誤。
2. 第二種方法是通過檔案租借鎖來解決這個問題的，這種方法相對來說更好一些。我們可以通過核心對檔案加讀或者寫的租借鎖，當另外一個進程嘗試對使用者進行中傳輸的檔案進行截斷的時候，核心會發送給使用者一個即時訊號：RT_SIGNAL_LEASE 訊號，這個訊號會告訴使用者核心破壞了使用者加在那個檔案上的寫或者讀租借鎖，那麼 write() 系統調用則會被中斷，並且進程會被 SIGBUS 訊號殺死，傳回值則是中斷前寫的位元組數，errno 也會被設定為 success。檔案租借鎖需要在對檔案進行記憶體映射之前設定。

使用 mmap 是 POSIX 相容的，但是使用 mmap 並不一定能獲得理想的資料轉送效能。資料轉送的過程中仍然需要一次 CPU 拷貝操作，而且映射操作也是一個開銷很大的虛擬儲存操作，這種操作需要通過更改頁表以及沖刷 TLB （使得 TLB 的內容無效）來維持儲存的一致性。但是，因為映射通常適用於較大範圍，所以對於相同長度的資料來說，映射所帶來的開銷遠遠低於 CPU 拷貝所帶來的開銷。

sendfile()

為了簡化使用者介面，同時還要繼續保留 mmap()/write() 技術的優點：減少 CPU 的拷貝次數，Linux 在版本 2.1 中引入了 sendfile() 這個系統調用。

sendfile() 不僅減少了資料拷貝操作，它也減少了環境切換。首先：sendfile() 系統調用利用 DMA 引擎將檔案中的資料拷貝到作業系統核心緩衝區中，然後資料被拷貝到與 socket 相關的核心緩衝區中去。接下來，DMA 引擎將資料從核心 socket 緩衝區中拷貝到協議引擎中去。如果在使用者調用 sendfile () 系統調用進行資料轉送的過程中有其他進程截斷了該檔案，那麼 sendfile () 系統調用會簡單地返回給使用者應用程式中斷前所傳輸的位元組數，errno 會被設定為 success。如果在調用
sendfile() 之前作業系統對檔案加上了租借鎖，那麼 sendfile() 的操作和返回狀態將會和 mmap()/write () 一樣。

圖 3. 利用 sendfile () 進行資料轉送

sendfile() 系統調用不需要將資料拷貝或者映射到應用程式地址空間中去，所以 sendfile() 只是適用於應用程式地址空間不需要對所訪問資料進行處理的情況。相對於 mmap() 方法來說，因為 sendfile 傳輸的資料沒有越過使用者應用程式 / 作業系統核心的邊界線，所以 sendfile () 也極大地減少了儲存管理的開銷。但是，sendfile () 也有很多局限性，如下所列：

• sendfile() 局限於基於檔案服務的網路應用程式，比如 網頁伺服器。據說，在 Linux 核心中實現 sendfile() 只是為了在其他平台上使用 sendfile() 的 Apache 程式。
• 由於網路傳輸具有非同步性，很難在 sendfile () 系統調用的接收端進行配對的實現方式，所以資料轉送的接收端一般沒有用到這種技術。
• 基於效能的考慮來說，sendfile () 仍然需要有一次從檔案到 socket 緩衝區的 CPU 拷貝操作，這就導致頁緩衝有可能會被傳輸的資料所汙染。

帶有 DMA 收集拷貝功能的 sendfile()
上小節介紹的 sendfile() 技術在進行資料轉送仍然還需要一次多餘的資料拷貝操作，通過引入一點硬體上的協助，這僅有的一次資料拷貝操作也可以避免。為了避免作業系統核心造成的資料副本，需要用到一個支援收集操作的網路介面，這也就是說，待傳輸的資料可以分散在儲存的不同位置上，而不需要在連續儲存中存放。這樣一來，從檔案中讀出的資料就根本不需要被拷貝到 socket 緩衝區中去，而只是需要將緩衝區描述符傳到網路通訊協定棧中去，之後其在緩衝區中建立起資料包的相關結構，然後通過 DMA 收集拷貝功能將所有的資料結合成一個網路資料包。網卡的
DMA 引擎會在一次操作中從多個位置讀取包頭和資料。Linux 2.4 版本中的 socket 緩衝區就可以滿足這種條件，這也就是用於 Linux 中的眾所周知的零拷貝技術，這種方法不但減少了因為多次環境切換所帶來開銷，同時也減少了處理器造成的資料副本的個數。對於使用者應用程式來說，代碼沒有任何改變。首先，sendfile() 系統調用利用 DMA 引擎將檔案內容拷貝到核心緩衝區去；然後，將帶有檔案位置和長度資訊的緩衝區描述符添加到 socket 緩衝區中去，此過程不需要將資料從作業系統核心緩衝區拷貝到 socket
緩衝區中，DMA 引擎會將資料直接從核心緩衝區拷貝到協議引擎中去，這樣就避免了最後一次資料拷貝。

圖 4. 帶有 DMA 收集拷貝功能的 sendfile

通過這種方法，CPU 在資料轉送的過程中不但避免了資料拷貝操作，理論上，CPU 也永遠不會跟傳輸的資料有任何關聯，這對於 CPU 的效能來說起到了積極的作用：首先，高速緩衝儲存空間沒有受到汙染；其次，高速緩衝儲存空間的一致性不需要維護，高速緩衝儲存空間在 DMA 進行資料轉送前或者傳輸後不需要被重新整理。然而實際上，後者實現起來非常困難。源緩衝區有可能是頁緩衝的一部分，這也就是說一般的讀操作可以訪問它，而且該訪問也可以是通過傳統方式進行的。只要儲存地區可以被 CPU 訪問到，那麼高速緩衝儲存空間的一致性就需要通過
DMA 傳輸之前沖重新整理高速緩衝儲存空間來維護。而且，這種資料收集拷貝功能的實現是需要硬體以及裝置驅動程式支援的。

splice()

splice() 是　 Linux 　中與 mmap() 和　 sendfile() 類似的一種方法。它也可以用於使用者應用程式地址空間和作業系統地址空間之間的資料轉送。splice() 適用於可以確定資料轉送路徑的使用者應用程式，它不需要利用使用者地址空間的緩衝區進行顯式的資料轉送操作。那麼，當資料只是從一個地方傳送到另一個地方，過程中所傳輸的資料不需要經過使用者應用程式的處理的時候，spice() 就成為了一種比較好的選擇。splice() 可以在作業系統地址空間中整塊地移動資料，從而減少大多數資料拷貝操作。而且，splice()
進行資料轉送可以通過非同步方式來進行，使用者應用程式可以先從系統調用返回，而作業系統核心進程會控制資料轉送過程繼續進行下去。splice() 可以被看成是類似於基於流的管道的實現，管道可以使得兩個檔案描述符相互串連，splice 的調用者則可以控制兩個裝置（或者協議棧）在作業系統核心中的相互串連。

splice() 系統調用和 sendfile() 非常類似，使用者應用程式必須擁有兩個已經開啟的檔案描述符，一個用於表示輸入裝置，一個用於表示輸出裝置。與 sendfile() 不同的是，splice() 允許任意兩個檔案之間互相串連，而並不只是檔案到 socket 進行資料轉送。對於從一個檔案描述符發送資料到 socket 這種特例來說，一直都是使用 sendfile() 這個系統調用，而 splice 一直以來就只是一種機制，它並不僅限於 sendfile() 的功能。也就是說，sendfile() 只是
splice() 的一個子集，在 Linux 2.6.23 中，sendfile() 這種機制的實現已經沒有了，但是這個 API 以及相應的功能還存在，只不過 API 以及相應的功能是利用了 splice() 這種機制來實現的。

在資料轉送的過程中，splice() 機制交替地發送相關的檔案描述符的讀寫操作，並且可以將讀緩衝區重新用於寫操作。它也利用了一種簡單的流量控制，通過預先定義的浮水印（ watermark ）來阻塞寫請求。有實驗表明，利用這種方法將資料從一個磁碟傳輸到另一個磁碟會增加 30% 到 70% 的輸送量，資料轉送的過程中， CPU 的負載也會減少一半。

Linux 2.6.17 核心引入了 splice() 系統調用，但是，這個概念在此之前 ] 其實已經存在了很長一段時間了。1988 年，Larry McVoy 提出了這個概念，它被看成是一種改進伺服器端系統的 I/O 效能的一種技術，儘管在之後的若干年中經常被提及，但是 splice 系統調用從來沒有在主流的 Linux 作業系統核心中實現過，一直到 Linux 2.6.17 版本的出現。splice 系統調用需要用到四個參數，其中兩個是檔案描述符，一個表示檔案長度，還有一個用於控制如何進行資料拷貝。splice
系統調用可以同步實現，也可以使用非同步方式來實現。在使用非同步方式的時候，使用者應用程式會通過訊號 SIGIO 來獲知資料轉送已經終止。splice() 系統調用的介面如下所示：

long splice(int fdin, int fdout, size_t len, unsigned int flags);

調用 splice() 系統調用會導致作業系統核心從資料來源 fdin 移動最多 len 個位元組的資料到 fdout 中去，這個資料的移動過程只是經過作業系統核心空間，需要最少的拷貝次數。使用 splice() 系統調用需要這兩個檔案描述符中的一個必須是用來表示一個管道裝置的。不難看出，這種設計具有局限性，Linux 的後續版本針對這一問題將會有所改進。參數 flags 用於表示拷貝操作的執行方法，當前的 flags 有如下這些取值：

• SPLICE_F_NONBLOCK：splice 操作不會被阻塞。然而，如果檔案描述符沒有被設定為不可被阻塞方式的 I/O ，那麼調用 splice 有可能仍然被阻塞。
• SPLICE_F_MORE：告知作業系統核心下一個 splice 系統調用將會有更多的資料傳來。
• SPLICE_F_MOVE：如果輸出是檔案，這個值則會使得作業系統核心嘗試從輸入管道緩衝區直接將資料讀入到輸出地址空間，這個資料轉送過程沒有任何資料拷貝操作發生。

Splice() 系統調用利用了 Linux 提出的管道緩衝區（ pipe buffer ）機制，這就是為什麼這個系統調用的兩個檔案描述符參數中至少有一個必須要指代管道裝置的原因。為了支援 splice 這種機制，Linux 在用於裝置和檔案系統的 file_operations 結構中增加了下邊這兩個定義：

ssize_t (*splice_write)(struct inode *pipe, strucuct file *out,                        size_t len, unsigned int flags);  ssize_t (*splice_read)(struct inode *in, strucuct file *pipe,                        size_t len, unsigned int flags); 

這兩個新的操作可以根據 flags 的設定在 pipe 和 in 或者 out 之間移動 len 個位元組。Linux 檔案系統已經實現了具有上述功能並且可以使用的操作，而且還實現了一個 generic_splice_sendpage() 函數用於和 socket 之間的接合。

對應用程式地址空間和核心之間的資料轉送進行最佳化的零拷貝技術
前面提到的幾種零拷貝技術都是通過盡量避免使用者應用程式和作業系統核心緩衝區之間的資料拷貝來實現的，使用上面那些零拷貝技術的應用程式通常都要局限於某些特殊的情況：要麼不能在作業系統核心中處理資料，要麼不能在使用者地址空間中處理資料。而這一小節提出的零拷貝技術保留了傳統在使用者應用程式地址空間和作業系統核心地址空間之間傳遞資料的技術，但卻在傳輸上進行最佳化。我們知道，資料在系統軟體和硬體之間的傳遞可以通過 DMA 傳輸來提高效率，但是對於使用者應用程式和作業系統之間進行資料轉送這種情況來說，並沒有類似的工具可以使用。本節介紹的技術就是針對這種情況提出來的。
利用寫時複製
在某些情況下，Linux 作業系統核心中的頁緩衝可能會被多個應用程式所共用，作業系統有可能會將使用者應用程式地址空間緩衝區中的頁面映射到作業系統核心地址空間中去。如果某個應用程式想要對這共用的資料調用　 write() 系統調用，那麼它就可能破壞核心緩衝區中的共用資料，傳統的 write() 系統調用並沒有提供任何顯示的加鎖操作，Linux 中引入了寫時複製這樣一種技術用來保護資料。
什麼是寫時複製寫時複製是電腦編程中的一種最佳化策略，它的基本思想是這樣的：如果有多個應用程式需要同時訪問同一塊資料，那麼可以為這些應用程式分配指向這塊資料的指標，在每一個應用程式看來，它們都擁有這塊資料的一份資料拷貝，當其中一個應用程式需要對自己的這份資料拷貝進行修改的時候，就需要將資料真正地拷貝到該應用程式的地址空間中去，也就是說，該應用程式擁有了一份真正的私人資料拷貝，這樣做是為了避免該應用程式對這塊資料做的更改被其他應用程式看到。這個過程對於應用程式來說是透明的，如果應用程式永遠不會對所訪問的這塊資料進行任何更改，那麼就永遠不需要將資料拷貝到應用程式自己的地址空間中去。這也是寫時複製的最主要的優點。
寫時複製的實現需要 MMU 的支援，MMU 需要知曉進程地址空間中哪些特殊的頁面是唯讀，當需要往這些頁面中寫資料的時候，MMU 就會發出一個異常給作業系統核心，作業系統核心就會分配新的實體儲存體空間，即將被寫入資料的頁面需要與新的實體儲存體位置相對應。
寫時複製的最大好處就是可以節約記憶體。不過對於作業系統核心來說，寫時複製增加了其處理過程的複雜性。

資料轉送的實現及其局限性
資料發送端
對於資料轉送的發送端來說，實現相對來說是比較簡單的，對與應用程式緩衝區相關的物理頁面進行加鎖，並將這些頁面映射到作業系統核心的地址空間，並標識為“ write only ”。當系統調用返回的時候，使用者應用程式和網路堆棧就都可以讀取該緩衝區中的資料。在作業系統已經傳送完所有的資料之後，應用程式就可以對這些資料進行寫操作。如果應用程式嘗試在資料轉送完成之前對資料進行寫操作，那麼就會產生異常，這個時候作業系統就會將資料拷貝到應用程式自己的緩衝區中去，並且重設應用程式端的映射。資料轉送完成之後，對加鎖的頁面進行解鎖操作，並重設
COW 標識。

資料接收端
對於資料接收端來說，該技術的實現則需要處理複雜得多的情況。如果 read() 系統調用是在資料包到達之前發出的，並且應用程式是被阻塞的，那麼 read() 系統調用就會告知作業系統接收到的資料包中的資料應該存放到什麼地方去。在這種情況下，根本沒有必要進行頁面重新對應，網路介面卡可以提供足夠的支援讓資料直接存入使用者應用程式的緩衝區中去。如果資料接收是非同步，在 read() 系統調用發出之前，作業系統不知道該把資料寫到哪裡，因為它不知道使用者應用程式緩衝區的位置，所以作業系統核心必須要先把資料存放到自己的緩衝區中去。

局限性
寫時複製技術有可能會導致作業系統的處理開銷很大．所有相關的緩衝區都必須要進行頁對齊處理，並且使用的 MMU 頁面一定要是整數個的。對於發送端來說，這不會造成什麼問題。但是對於接收端來說，它需要有能力處理更加複雜的情況。首先，資料包的尺寸大小要合適，大小需要恰到好處能夠覆蓋一整頁的資料，這就限制了那些 MTU 大小大於系統記憶體頁的網路，比如 FDDI 和 ATM。其次，為了在沒有任何中斷的情況下將頁面重新對應到資料包的流，資料包中的資料部分必須佔用整數個頁面。對於非同步接收資料的情況來說，為了將資料高效地移動到使用者地址空間中去，可以使用這樣一種方法：利用網路介面卡的支援，傳來的資料包可以被分割成包頭和資料兩部分，資料被存放在一個單獨的緩衝區內，虛擬儲存系統然後就會將資料對應到使用者地址空間緩衝區去。使用這種方法需要滿足兩個先決條件，也就是上面提到過的：一是應用程式緩衝區必須是頁對齊的，並且在虛擬儲存上是連續的；二是傳來的資料有一頁大小的時候才可以對資料包進行分割。事實上，這兩個先決條件是很難滿足的。如果應用程式緩衝區不是頁對齊的，或者資料包的大小超過一個頁，那麼資料就需要被拷貝。對於資料發送端來說，就算資料在傳輸的過程中對於應用程式來說是防寫保護的，應用程式仍然需要避免使用這些忙緩衝區，這是因為寫時拷貝操作所帶來的開銷是很大的。如果沒有端到端這一層級的通知，那麼應用程式很難會知道某緩衝區是否已經被釋放還是仍然在被佔用。

這種零拷貝技術比較適用於那種寫時複製事件發生比較少的情況，因為寫時複製事件所產生的開銷要遠遠高於一次 CPU 拷貝所產生的開銷。實際情況中，大多數應用程式通常都會多次重複使用相同的緩衝區，所以，一次使用完資料之後，不要從作業系統地址空間解除頁面的映射，這樣會提高效率。考慮到同樣的頁面可能會被再次訪問，所以保留頁面的映射可以節省管理開銷，但是，這種映射保留不會減少由於頁表往返移動和 TLB 沖刷所帶來的開銷，這是因為每次頁面由於寫時複製而進行加鎖或者解鎖的時候，頁面的唯讀標誌都要被更改。

緩衝區共用
還有另外一種利用預先映射機制的共用緩衝區的方法也可以在應用程式地址空間和作業系統核心之間快速傳輸資料。採用緩衝區共用這種思想的架構最先在 Solaris 上實現，該架構使用了“ fbufs ”這個概念。這種方法需要修改 API。應用程式地址空間和作業系統核心地址空間之間的資料傳遞需要嚴格按照 fbufs 體繫結構來實現，作業系統核心之間的通訊也是嚴格按照 fbufs 體繫結構來完成的。每一個應用程式都有一個緩衝區池，這個緩衝區池被同時映射到使用者地址空間和核心地址空間，也可以在必要的時候才建立它們。通過完成一次虛擬儲存操作來建立緩衝區，fbufs
可以有效地減少由儲存一致性維護所引起的大多數效能問題。該技術在 Linux 中還停留在實驗階段。

為什麼要擴充 Linux I/O API
傳統的 Linux 輸入輸出介面，比如讀和寫系統調用，都是基於拷貝的，也就是說，資料需要在作業系統核心和應用程式定義的緩衝區之間進行拷貝。對於讀系統調用來說，使用者應用程式呈現給作業系統核心一個預先分配好的緩衝區，核心必須把讀進來的資料放到這個緩衝區內。對於寫系統調用來說，只要系統調用返回，使用者應用程式就可以自由重新利用資料緩衝區。

為了支援上面這種機制，Linux 需要能夠為每一個操作都進行建立和刪除虛擬儲存映射。這種頁面重新對應的機制依賴於機器配置、cache 體繫結構、TLB 未命中處理所帶來的開銷以及處理器是單一處理器還是多處理器等多種因素。如果能夠避免處理 I/O 請求的時候虛擬儲存 / TLB 操作所產生的開銷，則會極大地提高 I/O 的效能。fbufs 就是這樣一種機制。使用 fbufs 體繫結構就可以避免虛擬儲存操作。由資料顯示，fbufs 這種結構在 DECStation 5000/200 這個單一處理器工作站上會取得比上面提到的頁面重新對應方法好得多的效能。如果要使用
fbufs 這種體繫結構，必須要擴充 Linux API，從而實現一種有效而且全面的零拷貝技術。

快速緩衝區（ Fast Buffers ）原理介紹
I/O 資料存放在一些被稱作 fbufs 的緩衝區內，每一個這樣的緩衝區都包含一個或者多個連續的虛擬儲存頁。應用程式訪問 fbuf 是通過保護域來實現的，有如下這兩種方式：

• 如果應用程式分配了 fbuf，那麼應用程式就有訪問該 fbuf 的許可權
• 如果應用程式通過 IPC 接收到了 fbuf，那麼應用程式對這個 fbuf 也有訪問的許可權

對於第一種情況來說，這個保護域被稱作是 fbuf 的“ originator ”；對於後一種情況來說，這個保護域被稱作是 fbuf 的“ receiver ”。

傳統的 Linux I/O 介面支援資料在應用程式地址空間和作業系統核心之間交換，這種交換操作導致所有的資料都需要進行拷貝。如果採用 fbufs 這種方法，需要交換的是包含資料的緩衝區，這樣就消除了多餘的拷貝操作。應用程式將 fbuf 傳遞給作業系統核心，這樣就能減少傳統的 write 系統調用所產生的資料拷貝開銷。同樣的，應用程式通過 fbuf 來接收資料，這樣也可以減少傳統 read 系統調用所產生的資料拷貝開銷。如所示：

圖 5. Linux I/O API

I/O 子系統或者應用程式都可以通過 fbufs 管理器來分配 fbufs。一旦分配了 fbufs，這些 fbufs 就可以從程式傳遞到 I/O 子系統，或者從 I/O 子系統傳遞到程式。使用完後，這些 fbufs 會被釋放回 fbufs 緩衝區池。

fbufs 在實現上有如下這些特性， 6 所示：

• fbuf 需要從 fbufs 緩衝區池裡分配。每一個 fbuf 都存在一個所屬對象，要麼是應用程式，要麼是作業系統核心。fbuf 可以在應用程式和作業系統之間進行傳遞，fbuf 使用完之後需要被釋放回特定的 fbufs 緩衝區池，在 fbuf 傳遞的過程中它們需要攜帶關於 fbufs 緩衝區池的相關資訊。
• 每一個 fbufs 緩衝區池都會和一個應用程式相關聯，一個應用程式最多隻能與一個 fbufs 緩衝區池相關聯。應用程式只有資格訪問它自己的緩衝區池。
• fbufs 不需要虛擬位址重新對應，這是因為對於每個應用程式來說，它們可以重新使用相同的緩衝區集合。這樣，虛擬儲存轉換的資訊就可以被緩衝起來，虛擬儲存子系統方面的開銷就可以消除。
• I/O 子系統（裝置驅動程式，檔案系統等）可以分配 fbufs，並將到達的資料直接放到這些 fbuf 裡邊。這樣，緩衝區之間的拷貝操作就可以避免。

圖 6. fbufs 體繫結構

前面提到，這種方法需要修改 API，如果要使用 fbufs 體繫結構，應用程式和 Linux 作業系統核心驅動程式都需要使用新的 API，如果應用程式要發送資料，那麼它就要從緩衝區池裡擷取一個 fbuf，將資料填充進去，然後通過檔案描述符將資料發送出去。接收到的 fbufs 可以被應用程式保留一段時間，之後，應用程式可以使用它繼續發送其他的資料，或者還給緩衝區池。但是，在某些情況下，需要對資料包內的資料進行重新組裝，那麼通過 fbuf 接收到資料的應用程式就需要將資料拷貝到另外一個緩衝區內。再者，應用程式不能對當前正在被核心處理的資料進行修改，基於這一點，fbufs
體繫結構引入了強制鎖的概念以保證其實現。對於應用程式來說，如果 fbufs 已經被發送給作業系統核心，那麼應用程式就不會再處理這些 fbufs。

fbufs 存在的一些問題

管理共用緩衝區池需要應用程式、網路軟體、以及裝置驅動程式之間的緊密合作。對於資料接收端來說，網路硬體必須要能夠將到達的資料包利用 DMA 傳輸到由接收端分配的正確的儲存緩衝區池中去。而且，應用程式稍微不注意就會更改之前發到共用儲存中的資料的內容，從而導致資料被破壞，但是這種問題在應用程式端是很難調試的。同時，共用儲存這種模型很難與其他類型的儲存物件關聯使用，但是應用程式、網路軟體以及裝置驅動程式之間的緊密合作是需要其他儲存管理器的支援的。對於共用緩衝區這種技術來說，雖然這種技術看起來前景光明，但是這種技術不但需要對
API 變更，而且需要對驅動程式也變更，並且這種技術本身也存在一些未解決的問題，這就使得這種技術目前還只是出於實驗階段。在測試系統中，這種技術在效能上有很大的改進，不過這種新的架構的整體安裝目前看起來還是不可行的。這種預先分配共用緩衝區的機制有時也因為粒度問題需要將資料拷貝到另外一個緩衝區中去。

總結
本系列文章介紹了 Linux 中的零拷貝技術，本文是其中的第二部分。本文對第一部分文章中提出的 Linux 作業系統上出現的幾種零拷貝技術進行了更詳細的介紹，主要描述了它們各自的優點，缺點以及適用情境。對於網路資料轉送來說，零拷貝技術的應用受到了很多體繫結構方面因素的阻礙，包括虛擬儲存體繫結構以及網路通訊協定體繫結構等。所以，零拷貝技術仍然只是在某些很特殊的情況中才可以應用，比如檔案服務或者使用某種特殊的協議進行高頻寬的通訊等。但是，零拷貝技術在磁碟操作中的應用的可行性就高得多了，這很可能是因為磁碟操作具有同步的特點，以及數據傳輸單元是按照頁的粒度來進行的。

針對 Linux 作業系統平台提出並實現了很多種零拷貝技術，但是並不是所有這些零拷貝技術都被廣泛應用於現實中的作業系統中的。比如，fbufs 體繫結構，它在很多方面看起來都很吸引人，但是使用它需要更改 API 以及驅動程式，它還存在其他一些實現上的困難，這就使得 fbufs 還只是停留在實驗的階段。動態地址重新對應技術只是需要對作業系統做少量修改，雖然不需要修改使用者軟體，但是當前的虛擬儲存體繫結構並不能很好地支援頻繁的虛擬位址重新對應操作。而且為了保證儲存的一致性，重新對應之後還必須對 TLB 和一級緩衝進行重新整理。事實上，利用地址重新對應實現的零拷貝技術適用的範圍是很小的，這是因為虛擬儲存操作所帶來的開銷往往要比
CPU 拷貝所產生的開銷還要大。此外，為了完全消除 CPU 訪問儲存，通常都需要額外的硬體來支援，而這種硬體的支援並不是很普及，同時也是非常昂貴的。

本系列文章的目的是想協助讀者理清這些出現在 Linux 作業系統中的零拷貝技術都是從何種角度來協助改善資料轉送過程中遇到的效能問題的。關於各種零拷貝技術的具體實現細節，本系列文章沒有做詳細描述。同時，零拷貝技術一直是在不斷地發展和完善當中的，本系列文章並沒有涵蓋 Linux 上出現的所有零拷貝技術。

參考資料

學習

• 參考本系列的第一部分：Linux 中的零拷貝技術，第 1 部分 概述。 

• Zero Copy I: User-Mode Perspective, Linux Journal (2003), http://www.linuxjournal.com/node/6345描述了幾種 Linux 作業系統中存在的零拷貝技術。

• 在 http://www.ibm.com/developerworks/cn/aix/library/au-tcpsystemcalls/這篇文章中可以找到關於 TCP 系統調用序列的介紹。

• 關於 Linux 中直接 I/O 技術的設計與實現請參考 developerWorks 上的文章 ”Linux 中直接 I/O 機制的介紹”。

• http://lwn.net/Articles/28548/上可以找到 Linux 上零拷貝技術中關於使用者地址空間訪問技術的介紹。

• http://articles.techrepublic.com.com/5100-10878_11-1044112.html?tag=content;leftCol，這篇文章描述了如何利用 sendfile() 最佳化資料轉送的介紹。

• 關於 splice() 系統調用的介紹，可以參考 http://lwn.net/Articles/178199/。

• http://en.scientificcommons.org/43480276這篇文章介紹了如何通過在作業系統核心中直接傳輸資料來提高 I/O 的效能以及 CPU 的可用性，並詳細描述了 splice 系統調用如何在使用者應用程式不參與的情況下進行非同步資料轉送。

• 在 Understanding the Linux Kernel(3rd Edition) 中，有關於 Linux 核心的實現。 

• http://pages.cs.wisc.edu/~cao/cs736/slides/cs736-class18.ps這篇文章提出並詳細介紹了 fbufs 這種用於 I/O 緩衝區管理的機制，以及基於共用儲存的資料轉送機制。

• http://www.cs.inf.ethz.ch/group/stricker/sada/archive/chihaia.pdf，這篇文章列舉了一些 Linux 中出現的零拷貝技術，並在測試系統上實現了 fbufs 技術。 

• 在 developerWorks Linux 專區尋找為 Linux 開發人員（包括 Linux 新手入門）準備的更多參考資料，查閱我們 最受歡迎的文章和教程。

• 在 developerWorks 上查閱所有 Linux 技巧和 Linux
  教程。

• 隨時關注 developerWorks 技術活動和 網路廣播。

討論

• 歡迎加入 My developerWorks 中文社區。

原文：http://www.ibm.com/developerworks/cn/linux/l-cn-zerocopy2/index.html