linux中直接 I/O 機制的介紹

轉自 

http://www.ibm.com/developerworks/cn/linux/l-cn-directio/

在介紹直接 I/O 之前，這一小節先介紹一下為什麼會出現直接 I/O 這種機制，即傳統的 I/O 操作存在哪些缺點。

緩衝 I/O 又被稱作標準 I/O，大多數檔案系統的預設 I/O 操作都是緩衝 I/O。在 Linux 的緩衝 I/O 機制中，作業系統會將 I/O 的資料緩衝在檔案系統的頁緩衝（ page cache ）中，也就是說，資料會先被拷貝到作業系統核心的緩衝區中，然後才會從作業系統核心的緩衝區拷貝到應用程式的地址空間。緩衝 I/O 有以下這些優點：

• 緩衝 I/O 使用了作業系統核心緩衝區，在一定程度上分離了應用程式空間和實際的物理裝置。 

• 緩衝 I/O 可以減少讀盤的次數，從而提高效能。 

當應用程式嘗試讀取某塊資料的時候，如果這塊資料已經存放在了頁緩衝中，那麼這塊資料就可以立即返回給應用程式，而不需要經過實際的物理讀盤操作。當然，如果資料在應用程式讀取之前並未被存放在頁緩衝中，那麼就需要先將資料從磁碟讀到頁緩衝中去。對於寫操作來說，應用程式也會將資料先寫到頁緩衝中去，資料是否被立即寫到磁碟上去取決於應用程式所採用的寫操作機制：如果使用者採用的是同步寫機制（ synchronous writes ）, 那麼資料會立即被寫回到磁碟上，應用程式會一直等到資料被寫完為止；如果使用者採用的是延遲寫機制（ deferred writes ），那麼應用程式就完全不需要等到資料全部被寫回到磁碟，資料只要被寫到頁緩衝中去就可以了。在延遲寫機制的情況下，作業系統會定期地將放在頁緩衝中的資料刷到磁碟上。與非同步寫機制（ asynchronous writes ）不同的是，延遲寫機制在資料完全寫到磁碟上的時候不會通知應用程式，而非同步寫機制在資料完全寫到磁碟上的時候是會返回給應用程式的。所以延遲寫機制本身是存在資料丟失的風險的，而非同步寫機制則不會有這方面的擔心。

緩衝 I/O 的缺點

在緩衝 I/O 機制中，DMA 方式可以將資料直接從磁碟讀到頁緩衝中，或者將資料從頁緩衝直接寫回到磁碟上，而不能直接在應用程式地址空間和磁碟之間進行資料轉送，這樣的話，資料在傳輸過程中需要在應用程式地址空間和頁緩衝之間進行多次資料拷貝操作，這些資料拷貝操作所帶來的 CPU 以及記憶體開銷是非常大的。

對於某些特殊的應用程式來說，避開作業系統核心緩衝區而直接在應用程式地址空間和磁碟之間傳輸資料會比使用作業系統核心緩衝區擷取更好的效能，下邊這一小節中提到的自緩衝應用程式就是其中的一種。

自緩衝應用程式（ self-caching applications）

對於某些應用程式來說，它會有它自己的資料緩衝機制，比如，它會將資料緩衝在應用程式地址空間，這類應用程式完全不需要使用作業系統核心中的高速緩衝儲存空間，這類應用程式就被稱作是自緩衝應用程式（ self-caching applications ）。資料庫管理系統是這類應用程式的一個代表。自緩衝應用程式傾向於使用資料的邏輯表達方式，而非物理表達方式；當系統記憶體較低的時候，自緩衝應用程式會讓這種資料的邏輯緩衝被換出，而並非是磁碟上實際的資料被換出。自緩衝應用程式對要操作的資料的語義了如指掌，所以它可以採用更加高效的緩衝替換演算法。自緩衝應用程式有可能會在多台主機之間共用一塊記憶體，那麼自緩衝應用程式就需要提供一種能夠有效地將使用者地址空間的快取資料置為無效的機制，從而確保應用程式地址空間快取資料的一致性。

對於自緩衝應用程式來說，緩衝 I/O 明顯不是一個好的選擇。由此引出我們這篇文章著重要介紹的 Linux 中的直接 I/O 技術。Linux 中的直接 I/O 技術非常適用於自緩衝這類應用程式，該技術省略掉緩衝 I/O 技術中作業系統核心緩衝區的使用，資料直接在應用程式地址空間和磁碟之間進行傳輸，從而使得自緩衝應用程式可以省略掉複雜的系統層級的緩衝結構，而執行程式自己定義的資料讀寫管理，從而降低系統層級的管理對應用程式訪問資料的影響。在下面一節中，我們會著重介紹 Linux 中提供的直接 I/O 機制的設計與實現，該機製為自緩衝應用程式提供了很好的支援。

回頁首

Linux 2.6 中的直接 I/O 技術

Linux 2.6 中提供的幾種檔案訪問方式

所有的 I/O 操作都是通過讀檔案或者寫檔案來完成的。在這裡，我們把所有的外圍裝置，包括鍵盤和顯示器，都看成是檔案系統中的檔案。訪問檔案的方法多種多樣，這裡列出下邊這幾種 Linux 2.6 中支援的檔案訪問方式。

標準訪問檔案的方式

在 Linux 中，這種訪問檔案的方式是通過兩個系統調用實現的：read() 和 write()。當應用程式調用 read() 系統調用讀取一塊資料的時候，如果該塊資料已經在記憶體中了，那麼就直接從記憶體中讀出該資料並返回給應用程式；如果該塊資料不在記憶體中，那麼資料會被從磁碟上讀到頁高緩衝中去，然後再從頁緩衝中拷貝到使用者地址空間中去。如果一個進程讀取某個檔案，那麼其他進程就都不可以讀取或者更改該檔案；對於寫資料操作來說，當一個進程調用了 write() 系統調用往某個檔案中寫資料的時候，資料會先從使用者地址空間拷貝到作業系統核心地址空間的頁緩衝中去，然後才被寫到磁碟上。但是對於這種標準的訪問檔案的方式來說，在資料被寫到頁緩衝中的時候，write() 系統調用就算執行完成，並不會等資料完全寫入到磁碟上。Linux 在這裡採用的是我們前邊提到的延遲寫機制（ deferred writes ）。

圖 1. 以標準的方式對檔案進行讀寫

同步訪問檔案的方式

同步訪問檔案的方式與上邊這種標準的訪問檔案的方式比較類似，這兩種方法一個很關鍵的區別就是：同步訪問檔案的時候，寫資料的操作是在資料完全被寫回磁碟上才算完成的；而標準訪問檔案方式的寫資料操作是在資料被寫到頁高速緩衝儲存空間中的時候就算執行完成了。

圖 2. 資料同步寫回磁碟

記憶體映射方式

在很多作業系統包括 Linux 中，記憶體地區（ memory region ）是可以跟一個普通的檔案或者塊裝置檔案的某一個部分關聯起來的，若進程要訪問記憶體頁中某個位元組的資料，作業系統就會將訪問該記憶體地區的操作轉換為相應的訪問檔案的某個位元組的操作。Linux 中提供了系統調用 mmap() 來實現這種檔案訪問方式。與標準的訪問檔案的方式相比，記憶體映射方式可以減少標準訪問檔案方式中 read() 系統調用所帶來的資料拷貝操作，即減少資料在使用者地址空間和作業系統核心地址空間之間的拷貝操作。映射通常適用於較大範圍，對於相同長度的資料來講，映射所帶來的開銷遠遠低於 CPU 拷貝所帶來的開銷。當大量資料需要傳輸的時候，採用記憶體映射方式去訪問檔案會獲得比較好的效率。

圖 3. 利用 mmap 代替 read

直接 I/O 方式

凡是通過直接 I/O 方式進行資料轉送，資料均直接在使用者地址空間的緩衝區和磁碟之間直接進行傳輸，完全不需要頁緩衝的支援。作業系統層提供的緩衝往往會使應用程式在讀寫資料的時候獲得更好的效能，但是對於某些特殊的應用程式，比如說資料庫管理系統這類應用，他們更傾向於選擇他們自己的緩衝機制，因為資料庫管理系統往往比作業系統更瞭解資料庫中存放的資料，資料庫管理系統可以提供一種更加有效緩衝機制來提高資料庫中資料的存取效能。

圖 4. 資料轉送不經過作業系統核心緩衝區

非同步訪問檔案的方式

Linux 非同步 I/O 是 Linux 2.6 中的一個標準特性，其本質思想就是進程發出資料轉送請求之後，進程不會被阻塞，也不用等待任何操作完成，進程可以在資料轉送的時候繼續執行其他的操作。相對於同步訪問檔案的方式來說，非同步訪問檔案的方式可以提高應用程式的效率，並且提高系統資源使用率。直接 I/O 經常會和非同步訪問檔案的方式結合在一起使用。

圖 5.CPU 處理其他任務和 I/O 操作可以重疊執行

在下邊這一小節中，我們會重點介紹 Linux 2.6 核心中直接 I/O 的設計與實現。

Linux 2.6 中直接 I/O 的設計與實現

在塊裝置或者網路裝置中執行直接 I/O 完全不用擔心實現直接 I/O 的問題，Linux 2.6 作業系統核心中高層代碼已經設定和使用了直接 I/O，驅動程式層級的代碼甚至不需要知道已經執行了直接 I/O；但是對於字元裝置來說，執行直接 I/O 是不可行的，Linux 2.6 提供了函數 get_user_pages() 用於實現直接 I/O。本小節會分別對這兩種情況進行介紹。