0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線(xiàn)課程
  • 觀(guān)看技術(shù)視頻
  • 寫(xiě)文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

深入理解Linux系統(tǒng)零拷貝技術(shù)

Linux愛(ài)好者 ? 來(lái)源:博客 ? 作者:Spongecaptain ? 2021-09-01 15:12 ? 次閱讀

內(nèi)存拷貝是比較耗時(shí)操作,零拷貝是常用優(yōu)化手段,今天分享的文章就是Linux系統(tǒng)零拷貝技術(shù),Kafka和MySQL開(kāi)源組件都用到這個(gè)核心技術(shù),希望大家可以掌握。

DMA 與零拷貝技術(shù)

注意事項(xiàng):除了 Direct I/O,與磁盤(pán)相關(guān)的文件讀寫(xiě)操作都有使用到 page cache 技術(shù)。

1. 數(shù)據(jù)的四次拷貝與四次上下文切換

很多應(yīng)用程序在面臨客戶(hù)端請(qǐng)求時(shí),可以等價(jià)為進(jìn)行如下的系統(tǒng)調(diào)用:

File.read(file, buf, len);

Socket.send(socket, buf, len);

例如消息中間件 Kafka 就是這個(gè)應(yīng)用場(chǎng)景,從磁盤(pán)中讀取一批消息后原封不動(dòng)地寫(xiě)入網(wǎng)卡(NIC,Network interface controller)進(jìn)行發(fā)送。

在沒(méi)有任何優(yōu)化技術(shù)使用的背景下,操作系統(tǒng)為此會(huì)進(jìn)行 4 次數(shù)據(jù)拷貝,以及 4 次上下文切換,如下圖所示:

如果沒(méi)有優(yōu)化,讀取磁盤(pán)數(shù)據(jù),再通過(guò)網(wǎng)卡傳輸?shù)膱?chǎng)景性能比較差:

4 次 copy:

CPU 負(fù)責(zé)將數(shù)據(jù)從磁盤(pán)搬運(yùn)到內(nèi)核空間的 Page Cache 中;

CPU 負(fù)責(zé)將數(shù)據(jù)從內(nèi)核空間的 Socket 緩沖區(qū)搬運(yùn)到的網(wǎng)絡(luò)中;

CPU 負(fù)責(zé)將數(shù)據(jù)從內(nèi)核空間的 Page Cache 搬運(yùn)到用戶(hù)空間的緩沖區(qū);

CPU 負(fù)責(zé)將數(shù)據(jù)從用戶(hù)空間的緩沖區(qū)搬運(yùn)到內(nèi)核空間的 Socket 緩沖區(qū)中;

4 次上下文切換:

read 系統(tǒng)調(diào)用時(shí):用戶(hù)態(tài)切換到內(nèi)核態(tài);

read 系統(tǒng)調(diào)用完畢:內(nèi)核態(tài)切換回用戶(hù)態(tài);

write 系統(tǒng)調(diào)用時(shí):用戶(hù)態(tài)切換到內(nèi)核態(tài);

write 系統(tǒng)調(diào)用完畢:內(nèi)核態(tài)切換回用戶(hù)態(tài);

我們不免發(fā)出抱怨:

CPU 全程負(fù)責(zé)內(nèi)存內(nèi)的數(shù)據(jù)拷貝還可以接受,因?yàn)樾蔬€算可以接受,但是如果要全程負(fù)責(zé)內(nèi)存與磁盤(pán)、網(wǎng)絡(luò)的數(shù)據(jù)拷貝,這將難以接受,因?yàn)榇疟P(pán)、網(wǎng)卡的速度遠(yuǎn)小于內(nèi)存,內(nèi)存又遠(yuǎn)遠(yuǎn)小于 CPU;

4 次 copy 太多了,4 次上下文切換也太頻繁了;

2. DMA 參與下的數(shù)據(jù)四次拷貝

DMA 技術(shù)很容易理解,本質(zhì)上,DMA 技術(shù)就是我們?cè)谥靼迳戏乓粔K獨(dú)立的芯片。在進(jìn)行內(nèi)存和 I/O 設(shè)備的數(shù)據(jù)傳輸?shù)臅r(shí)候,我們不再通過(guò) CPU 來(lái)控制數(shù)據(jù)傳輸,而直接通過(guò) DMA 控制器(DMA Controller,簡(jiǎn)稱(chēng) DMAC)。這塊芯片,我們可以認(rèn)為它其實(shí)就是一個(gè)協(xié)處理器(Co-Processor)。

DMAC 最有價(jià)值的地方體現(xiàn)在,當(dāng)我們要傳輸?shù)臄?shù)據(jù)特別大、速度特別快,或者傳輸?shù)臄?shù)據(jù)特別小、速度特別慢的時(shí)候。

比如說(shuō),我們用千兆網(wǎng)卡或者硬盤(pán)傳輸大量數(shù)據(jù)的時(shí)候,如果都用 CPU 來(lái)搬運(yùn)的話(huà),肯定忙不過(guò)來(lái),所以可以選擇 DMAC。而當(dāng)數(shù)據(jù)傳輸很慢的時(shí)候,DMAC 可以等數(shù)據(jù)到齊了,再發(fā)送信號(hào),給到 CPU 去處理,而不是讓 CPU 在那里忙等待。

注意,這里面的“協(xié)”字。DMAC 是在“協(xié)助”CPU,完成對(duì)應(yīng)的數(shù)據(jù)傳輸工作。在 DMAC 控制數(shù)據(jù)傳輸?shù)倪^(guò)程中,我們還是需要 CPU 的進(jìn)行控制,但是具體數(shù)據(jù)的拷貝不再由 CPU 來(lái)完成。

原本,計(jì)算機(jī)所有組件之間的數(shù)據(jù)拷貝(流動(dòng))必須經(jīng)過(guò) CPU,如下圖所示:

現(xiàn)在,DMA 代替了 CPU 負(fù)責(zé)內(nèi)存與磁盤(pán)以及內(nèi)存與網(wǎng)卡之間的數(shù)據(jù)搬運(yùn),CPU 作為 DMA 的控制者,如下圖所示:

但是 DMA 有其局限性,DMA 僅僅能用于設(shè)備之間交換數(shù)據(jù)時(shí)進(jìn)行數(shù)據(jù)拷貝,但是設(shè)備內(nèi)部的數(shù)據(jù)拷貝還需要 CPU 進(jìn)行,例如 CPU 需要負(fù)責(zé)內(nèi)核空間數(shù)據(jù)與用戶(hù)空間數(shù)據(jù)之間的拷貝(內(nèi)存內(nèi)部的拷貝),如下圖所示:

read buffer 也就是 page cache,socket buffer 也就是 Socket 緩沖區(qū)。

3. 零拷貝技術(shù)

3.1 什么是零拷貝技術(shù)?

零拷貝技術(shù)是一個(gè)思想[3],指的是指計(jì)算機(jī)執(zhí)行操作時(shí),CPU 不需要先將數(shù)據(jù)從某處內(nèi)存復(fù)制到另一個(gè)特定區(qū)域。

可見(jiàn),零拷貝的特點(diǎn)是 CPU 不全程負(fù)責(zé)內(nèi)存中的數(shù)據(jù)寫(xiě)入其他組件,CPU 僅僅起到管理的作用。但注意,零拷貝不是不進(jìn)行拷貝,而是 CPU 不再全程負(fù)責(zé)數(shù)據(jù)拷貝時(shí)的搬運(yùn)工作。如果數(shù)據(jù)本身不在內(nèi)存中,那么必須先通過(guò)某種方式拷貝到內(nèi)存中(這個(gè)過(guò)程 CPU 可以不參與),因?yàn)閿?shù)據(jù)只有在內(nèi)存中,才能被轉(zhuǎn)移,才能被 CPU 直接讀取計(jì)算。

零拷貝技術(shù)的具體實(shí)現(xiàn)方式有很多,例如:

sendfile

mmap

splice

直接 Direct I/O

不同的零拷貝技術(shù)適用于不同的應(yīng)用場(chǎng)景,下面依次進(jìn)行 sendfile、mmap、Direct I/O 的分析。

不過(guò)出于總結(jié)性的目的,我們?cè)谶@里先對(duì)下面的技術(shù)做一個(gè)前瞻性的總結(jié)。

DMA 技術(shù)回顧:DMA 負(fù)責(zé)內(nèi)存與其他組件之間的數(shù)據(jù)拷貝,CPU 僅需負(fù)責(zé)管理,而無(wú)需負(fù)責(zé)全程的數(shù)據(jù)拷貝;

使用 page cache 的 zero copy:

sendfile:一次代替 read/write 系統(tǒng)調(diào)用,通過(guò)使用 DMA 技術(shù)以及傳遞文件描述符,實(shí)現(xiàn)了 zero copy

mmap:僅代替 read 系統(tǒng)調(diào)用,將內(nèi)核空間地址映射為用戶(hù)空間地址,write 操作直接作用于內(nèi)核空間。通過(guò) DMA 技術(shù)以及地址映射技術(shù),用戶(hù)空間與內(nèi)核空間無(wú)須數(shù)據(jù)拷貝,實(shí)現(xiàn)了 zero copy

不使用 page cache 的 Direct I/O:讀寫(xiě)操作直接在磁盤(pán)上進(jìn)行,不使用 page cache 機(jī)制,通常結(jié)合用戶(hù)空間的用戶(hù)緩存使用。通過(guò) DMA 技術(shù)直接與磁盤(pán)/網(wǎng)卡進(jìn)行數(shù)據(jù)交互,實(shí)現(xiàn)了 zero copy

3.2 sendfile

snedfile 的應(yīng)用場(chǎng)景是:用戶(hù)從磁盤(pán)讀取一些文件數(shù)據(jù)后不需要經(jīng)過(guò)任何計(jì)算與處理就通過(guò)網(wǎng)絡(luò)傳輸出去。此場(chǎng)景的典型應(yīng)用是消息隊(duì)列。

在傳統(tǒng) I/O 下,正如第一節(jié)所示,上述應(yīng)用場(chǎng)景的一次數(shù)據(jù)傳輸需要四次 CPU 全權(quán)負(fù)責(zé)的拷貝與四次上下文切換,正如本文第一節(jié)所述。

sendfile 主要使用到了兩個(gè)技術(shù):

DMA 技術(shù);

傳遞文件描述符代替數(shù)據(jù)拷貝;

下面依次講解這兩個(gè)技術(shù)的作用。

1.利用 DMA 技術(shù)

sendfile 依賴(lài)于 DMA 技術(shù),將四次 CPU 全程負(fù)責(zé)的拷貝與四次上下文切換減少到兩次,如下圖所示:

DMA 負(fù)責(zé)磁盤(pán)到內(nèi)核空間中的 Page cache(read buffer)的數(shù)據(jù)拷貝以及從內(nèi)核空間中的 socket buffer 到網(wǎng)卡的數(shù)據(jù)拷貝。

2.傳遞文件描述符代替數(shù)據(jù)拷貝

傳遞文件描述可以代替數(shù)據(jù)拷貝,這是由于兩個(gè)原因:

page cache 以及 socket buffer 都在內(nèi)核空間中;

數(shù)據(jù)傳輸過(guò)程前后沒(méi)有任何寫(xiě)操作;

注意事項(xiàng):只有網(wǎng)卡支持 SG-DMA(The Scatter-Gather Direct Memory Access)技術(shù)才可以通過(guò)傳遞文件描述符的方式避免內(nèi)核空間內(nèi)的一次 CPU 拷貝。這意味著此優(yōu)化取決于 Linux 系統(tǒng)的物理網(wǎng)卡是否支持(Linux 在內(nèi)核 2.4 版本里引入了 DMA 的 scatter/gather – 分散/收集功能,只要確保 Linux 版本高于 2.4 即可)。

3.一次系統(tǒng)調(diào)用代替兩次系統(tǒng)調(diào)用

由于 sendfile 僅僅對(duì)應(yīng)一次系統(tǒng)調(diào)用,而傳統(tǒng)文件操作則需要使用 read 以及 write 兩個(gè)系統(tǒng)調(diào)用。

正因?yàn)槿绱耍瑂endfile 能夠?qū)⒂脩?hù)態(tài)與內(nèi)核態(tài)之間的上下文切換從 4 次講到 2 次。

另一方面,我們需要注意 sendfile 系統(tǒng)調(diào)用的局限性。如果應(yīng)用程序需要對(duì)從磁盤(pán)讀取的數(shù)據(jù)進(jìn)行寫(xiě)操作,例如解密或加密,那么 sendfile 系統(tǒng)調(diào)用就完全沒(méi)法用。這是因?yàn)橛脩?hù)線(xiàn)程根本就不能夠通過(guò) sendfile 系統(tǒng)調(diào)用得到傳輸?shù)臄?shù)據(jù)。

3.3 mmap

mmap 技術(shù)在[4] 中單獨(dú)展開(kāi),請(qǐng)移步閱讀。

3.4 Direct I/O

Direct I/O 即直接 I/O。其名字中的”直接”二字用于區(qū)分使用 page cache 機(jī)制的緩存 I/O。

緩存文件 I/O:用戶(hù)空間要讀寫(xiě)一個(gè)文件并不直接與磁盤(pán)交互,而是中間夾了一層緩存,即 page cache;

直接文件 I/O:用戶(hù)空間讀取的文件直接與磁盤(pán)交互,沒(méi)有中間 page cache 層;

“直接”在這里還有另一層語(yǔ)義:其他所有技術(shù)中,數(shù)據(jù)至少需要在內(nèi)核空間存儲(chǔ)一份,但是在 Direct I/O 技術(shù)中,數(shù)據(jù)直接存儲(chǔ)在用戶(hù)空間中,繞過(guò)了內(nèi)核。

此時(shí)用戶(hù)空間直接通過(guò) DMA 的方式與磁盤(pán)以及網(wǎng)卡進(jìn)行數(shù)據(jù)拷貝。

Direct I/O 的讀寫(xiě)非常有特點(diǎn):

Write 操作:由于其不使用 page cache,所以其進(jìn)行寫(xiě)文件,如果返回成功,數(shù)據(jù)就真的落盤(pán)了(不考慮磁盤(pán)自帶的緩存);

Read 操作:由于其不使用 page cache,每次讀操作是真的從磁盤(pán)中讀取,不會(huì)從文件系統(tǒng)的緩存中讀取。

事實(shí)上,即使 Direct I/O 還是可能需要使用操作系統(tǒng)的 fsync 系統(tǒng)調(diào)用。為什么?

這是因?yàn)殡m然文件的數(shù)據(jù)本身沒(méi)有使用任何緩存,但是文件的元數(shù)據(jù)仍然需要緩存,包括 VFS 中的 inode cache 和 dentry cache 等。

在部分操作系統(tǒng)中,在 Direct I/O 模式下進(jìn)行 write 系統(tǒng)調(diào)用能夠確保文件數(shù)據(jù)落盤(pán),但是文件元數(shù)據(jù)不一定落盤(pán)。如果在此類(lèi)操作系統(tǒng)上,那么還需要執(zhí)行一次 fsync 系統(tǒng)調(diào)用確保文件元數(shù)據(jù)也落盤(pán)。否則,可能會(huì)導(dǎo)致文件異常、元數(shù)據(jù)確實(shí)等情況。MySQL 的 O_DIRECT 與 O_DIRECT_NO_FSYNC 配置是一個(gè)具體案例[9]。

Direct I/O 的優(yōu)缺點(diǎn):

(1)優(yōu)點(diǎn)

Linux 中的直接 I/O 技術(shù)省略掉緩存 I/O 技術(shù)中操作系統(tǒng)內(nèi)核緩沖區(qū)的使用,數(shù)據(jù)直接在應(yīng)用程序地址空間和磁盤(pán)之間進(jìn)行傳輸,從而使得自緩存應(yīng)用程序可以省略掉復(fù)雜的系統(tǒng)級(jí)別的緩存結(jié)構(gòu),而執(zhí)行程序自己定義的數(shù)據(jù)讀寫(xiě)管理,從而降低系統(tǒng)級(jí)別的管理對(duì)應(yīng)用程序訪(fǎng)問(wèn)數(shù)據(jù)的影響。

與其他零拷貝技術(shù)一樣,避免了內(nèi)核空間到用戶(hù)空間的數(shù)據(jù)拷貝,如果要傳輸?shù)臄?shù)據(jù)量很大,使用直接 I/O 的方式進(jìn)行數(shù)據(jù)傳輸,而不需要操作系統(tǒng)內(nèi)核地址空間拷貝數(shù)據(jù)操作的參與,這將會(huì)大大提高性能。

(2)缺點(diǎn)

由于設(shè)備之間的數(shù)據(jù)傳輸是通過(guò) DMA 完成的,因此用戶(hù)空間的數(shù)據(jù)緩沖區(qū)內(nèi)存頁(yè)必須進(jìn)行 page pinning(頁(yè)鎖定),這是為了防止其物理頁(yè)框地址被交換到磁盤(pán)或者被移動(dòng)到新的地址而導(dǎo)致 DMA 去拷貝數(shù)據(jù)的時(shí)候在指定的地址找不到內(nèi)存頁(yè)從而引發(fā)缺頁(yè)錯(cuò)誤,而頁(yè)鎖定的開(kāi)銷(xiāo)并不比 CPU 拷貝小,所以為了避免頻繁的頁(yè)鎖定系統(tǒng)調(diào)用,應(yīng)用程序必須分配和注冊(cè)一個(gè)持久的內(nèi)存池,用于數(shù)據(jù)緩沖。

如果訪(fǎng)問(wèn)的數(shù)據(jù)不在應(yīng)用程序緩存中,那么每次數(shù)據(jù)都會(huì)直接從磁盤(pán)進(jìn)行加載,這種直接加載會(huì)非常緩慢。

在應(yīng)用層引入直接 I/O 需要應(yīng)用層自己管理,這帶來(lái)了額外的系統(tǒng)復(fù)雜性;

誰(shuí)會(huì)使用 Direct I/O?

IBM[5]的一篇文章指出,自緩存應(yīng)用程序( self-caching applications)可以選擇使用 Direct I/O。

自緩存應(yīng)用程序

對(duì)于某些應(yīng)用程序來(lái)說(shuō),它會(huì)有它自己的數(shù)據(jù)緩存機(jī)制,比如,它會(huì)將數(shù)據(jù)緩存在應(yīng)用程序地址空間,這類(lèi)應(yīng)用程序完全不需要使用操作系統(tǒng)內(nèi)核中的高速緩沖存儲(chǔ)器,這類(lèi)應(yīng)用程序就被稱(chēng)作是自緩存應(yīng)用程序( self-caching applications )。

例如,應(yīng)用內(nèi)部維護(hù)一個(gè)緩存空間,當(dāng)有讀操作時(shí),首先讀取應(yīng)用層的緩存數(shù)據(jù),如果沒(méi)有,那么就通過(guò) Direct I/O 直接通過(guò)磁盤(pán) I/O 來(lái)讀取數(shù)據(jù)。緩存仍然在應(yīng)用,只不過(guò)應(yīng)用覺(jué)得自己實(shí)現(xiàn)一個(gè)緩存比操作系統(tǒng)的緩存更高效。

數(shù)據(jù)庫(kù)管理系統(tǒng)是這類(lèi)應(yīng)用程序的一個(gè)代表。自緩存應(yīng)用程序傾向于使用數(shù)據(jù)的邏輯表達(dá)方式,而非物理表達(dá)方式;當(dāng)系統(tǒng)內(nèi)存較低的時(shí)候,自緩存應(yīng)用程序會(huì)讓這種數(shù)據(jù)的邏輯緩存被換出,而并非是磁盤(pán)上實(shí)際的數(shù)據(jù)被換出。自緩存應(yīng)用程序?qū)σ僮鞯臄?shù)據(jù)的語(yǔ)義了如指掌,所以它可以采用更加高效的緩存替換算法。自緩存應(yīng)用程序有可能會(huì)在多臺(tái)主機(jī)之間共享一塊內(nèi)存,那么自緩存應(yīng)用程序就需要提供一種能夠有效地將用戶(hù)地址空間的緩存數(shù)據(jù)置為無(wú)效的機(jī)制,從而確保應(yīng)用程序地址空間緩存數(shù)據(jù)的一致性。

另一方面,目前 Linux 上的異步 IO 庫(kù),其依賴(lài)于文件使用 O_DIRECT 模式打開(kāi),它們通常一起配合使用。

如何使用 Direct I/O?

用戶(hù)應(yīng)用需要實(shí)現(xiàn)用戶(hù)空間內(nèi)的緩存區(qū),讀/寫(xiě)操作應(yīng)當(dāng)盡量通過(guò)此緩存區(qū)提供。如果有性能上的考慮,那么盡量避免頻繁地基于 Direct I/O 進(jìn)行讀/寫(xiě)操作。

4. 典型案例

4.1 Kakfa

Kafka 作為一個(gè)消息隊(duì)列,涉及到磁盤(pán) I/O 主要有兩個(gè)操作:

Provider 向 Kakfa 發(fā)送消息,Kakfa 負(fù)責(zé)將消息以日志的方式持久化落盤(pán);

Consumer 向 Kakfa 進(jìn)行拉取消息,Kafka 負(fù)責(zé)從磁盤(pán)中讀取一批日志消息,然后再通過(guò)網(wǎng)卡發(fā)送;

Kakfa 服務(wù)端接收 Provider 的消息并持久化的場(chǎng)景下使用 mmap 機(jī)制[6],能夠基于順序磁盤(pán) I/O 提供高效的持久化能力,使用的 Java 類(lèi)為 java.nio.MappedByteBuffer。

Kakfa 服務(wù)端向 Consumer 發(fā)送消息的場(chǎng)景下使用 sendfile 機(jī)制[7],這種機(jī)制主要兩個(gè)好處:

sendfile 避免了內(nèi)核空間到用戶(hù)空間的 CPU 全程負(fù)責(zé)的數(shù)據(jù)移動(dòng);

sendfile 基于 Page Cache 實(shí)現(xiàn),因此如果有多個(gè) Consumer 在同時(shí)消費(fèi)一個(gè)主題的消息,那么由于消息一直在 page cache 中進(jìn)行了緩存,因此只需一次磁盤(pán) I/O,就可以服務(wù)于多個(gè) Consumer;

使用 mmap 來(lái)對(duì)接收到的數(shù)據(jù)進(jìn)行持久化,使用 sendfile 從持久化介質(zhì)中讀取數(shù)據(jù)然后對(duì)外發(fā)送是一對(duì)常用的組合。但是注意,你無(wú)法利用 sendfile 來(lái)持久化數(shù)據(jù),利用 mmap 來(lái)實(shí)現(xiàn) CPU 全程不參與數(shù)據(jù)搬運(yùn)的數(shù)據(jù)拷貝。

4.2 MySQL

MySQL 的具體實(shí)現(xiàn)比 Kakfa 復(fù)雜很多,這是因?yàn)橹С?SQL 查詢(xún)的數(shù)據(jù)庫(kù)本身比消息隊(duì)列對(duì)復(fù)雜很多。

MySQL 的零拷貝技術(shù)使用方式請(qǐng)移步我的另一篇文章[8]。

5. 總結(jié)

DMA 技術(shù)的推出使得內(nèi)存與其他組件,例如磁盤(pán)、網(wǎng)卡進(jìn)行數(shù)據(jù)拷貝時(shí),CPU 僅僅需要發(fā)出控制信號(hào),而拷貝數(shù)據(jù)的過(guò)程則由 DMA 負(fù)責(zé)完成。

Linux 的零拷貝技術(shù)有多種實(shí)現(xiàn)策略,但根據(jù)策略可以分為如下幾種類(lèi)型:

減少甚至避免用戶(hù)空間和內(nèi)核空間之間的數(shù)據(jù)拷貝:在一些場(chǎng)景下,用戶(hù)進(jìn)程在數(shù)據(jù)傳輸過(guò)程中并不需要對(duì)數(shù)據(jù)進(jìn)行訪(fǎng)問(wèn)和處理,那么數(shù)據(jù)在 Linux 的 Page Cache 和用戶(hù)進(jìn)程的緩沖區(qū)之間的傳輸就完全可以避免,讓數(shù)據(jù)拷貝完全在內(nèi)核里進(jìn)行,甚至可以通過(guò)更巧妙的方式避免在內(nèi)核里的數(shù)據(jù)拷貝。這一類(lèi)實(shí)現(xiàn)一般是是通過(guò)增加新的系統(tǒng)調(diào)用來(lái)完成的,比如 Linux 中的 mmap(),sendfile() 以及 splice() 等。

繞過(guò)內(nèi)核的直接 I/O:允許在用戶(hù)態(tài)進(jìn)程繞過(guò)內(nèi)核直接和硬件進(jìn)行數(shù)據(jù)傳輸,內(nèi)核在傳輸過(guò)程中只負(fù)責(zé)一些管理和輔助的工作。這種方式其實(shí)和第一種有點(diǎn)類(lèi)似,也是試圖避免用戶(hù)空間和內(nèi)核空間之間的數(shù)據(jù)傳輸,只是第一種方式是把數(shù)據(jù)傳輸過(guò)程放在內(nèi)核態(tài)完成,而這種方式則是直接繞過(guò)內(nèi)核和硬件通信,效果類(lèi)似但原理完全不同。

內(nèi)核緩沖區(qū)和用戶(hù)緩沖區(qū)之間的傳輸優(yōu)化:這種方式側(cè)重于在用戶(hù)進(jìn)程的緩沖區(qū)和操作系統(tǒng)的頁(yè)緩存之間的 CPU 拷貝的優(yōu)化。這種方法延續(xù)了以往那種傳統(tǒng)的通信方式,但更靈活。

作者:Spongecaptain

原文:https://spongecaptain.cool/SimpleClearFileIO/

編輯:jq

聲明:本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀(guān)點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • cpu
    cpu
    +關(guān)注

    關(guān)注

    68

    文章

    10772

    瀏覽量

    210437
  • Linux系統(tǒng)
    +關(guān)注

    關(guān)注

    4

    文章

    588

    瀏覽量

    27265
  • dma
    dma
    +關(guān)注

    關(guān)注

    3

    文章

    555

    瀏覽量

    100216
  • MySQL
    +關(guān)注

    關(guān)注

    1

    文章

    793

    瀏覽量

    26352
  • 零拷貝技
    +關(guān)注

    關(guān)注

    0

    文章

    2

    瀏覽量

    5979

原文標(biāo)題:深入理解零拷貝技術(shù)

文章出處:【微信號(hào):LinuxHub,微信公眾號(hào):Linux愛(ài)好者】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    磁盤(pán)拷貝機(jī)會(huì)拷貝刪除的內(nèi)容嗎

    磁盤(pán)拷貝機(jī),也稱(chēng)為硬盤(pán)克隆器或磁盤(pán)復(fù)制器,是一種用于復(fù)制硬盤(pán)驅(qū)動(dòng)器內(nèi)容的設(shè)備。它可以將一個(gè)硬盤(pán)上的所有數(shù)據(jù),包括操作系統(tǒng)、程序、文件和設(shè)置,復(fù)制到另一個(gè)硬盤(pán)上。這種設(shè)備在數(shù)據(jù)備份、系統(tǒng)遷移、硬盤(pán)
    的頭像 發(fā)表于 10-14 15:38 ?132次閱讀

    深入理解FPD-link III ADAS解串器HUB產(chǎn)品

    電子發(fā)燒友網(wǎng)站提供《深入理解FPD-link III ADAS解串器HUB產(chǎn)品.pdf》資料免費(fèi)下載
    發(fā)表于 09-06 09:58 ?0次下載
    <b class='flag-5'>深入理解</b>FPD-link III ADAS解串器HUB產(chǎn)品

    深入理解FFmpeg閱讀體驗(yàn)》FFmpeg攝像頭測(cè)試

    、前期工作 上文FFmpeg移植完成后,需要將x264/lib文件夾下的庫(kù)文件拷貝到開(kāi)發(fā)板的/lib/目錄下,將ffmpeg_install/lib文件夾下的庫(kù)文件全部拷貝到開(kāi)發(fā)板的/lib/目錄
    發(fā)表于 04-17 19:06

    深入理解FFmpeg閱讀體驗(yàn)》

    : ./configure --host=aarch64-linux --prefix=/home/x264 --enable-shared --disable-asm --enable-static
    發(fā)表于 04-16 22:54

    深入理解 Sora 的技術(shù)原理

    將去除噪音后的結(jié)果數(shù)據(jù),利用視頻解碼器進(jìn)行解碼,將低維潛在空間數(shù)據(jù)還原成原始視頻數(shù)據(jù),這里可以實(shí)現(xiàn)不同分辨率的視頻解碼。
    的頭像 發(fā)表于 04-05 09:19 ?1836次閱讀
    <b class='flag-5'>深入理解</b> Sora 的<b class='flag-5'>技術(shù)</b>原理

    深入理解 FPGA 的基礎(chǔ)結(jié)構(gòu)

    轉(zhuǎn)載地址:https://zhuanlan.zhihu.com/p/506828648 文章很詳細(xì)的介紹了FPGA的基礎(chǔ)結(jié)構(gòu),能更直觀(guān)的理解內(nèi)部結(jié)構(gòu)原理。對(duì)深入學(xué)習(xí)很有幫助。 以下是正文: 這一段
    發(fā)表于 04-03 17:39

    深入理解Linux網(wǎng)絡(luò)協(xié)議

    網(wǎng)絡(luò)分層解決了網(wǎng)絡(luò)復(fù)雜的問(wèn)題,在網(wǎng)絡(luò)中傳輸數(shù)據(jù)中,我們對(duì)不同設(shè)備之間的傳輸數(shù)據(jù)的格式,需要定義一個(gè)數(shù)據(jù)標(biāo)準(zhǔn),所以就有了網(wǎng)絡(luò)協(xié)議。
    發(fā)表于 04-01 14:20 ?285次閱讀
    <b class='flag-5'>深入理解</b><b class='flag-5'>Linux</b>網(wǎng)絡(luò)協(xié)議

    深入理解光耦模擬隔離放大電路的技術(shù)奧秘

    深入理解光耦模擬隔離放大電路的技術(shù)奧秘 ?編輯 ▲ 圖1 仿真原理圖二、原理分析 之所以這個(gè)電路圖看起來(lái)容易讓人感到困惑,實(shí)際上就是這個(gè)仿真電路中,錯(cuò)誤的使用了這樣的光電三極管來(lái)表示HCNR201
    發(fā)表于 01-10 10:12

    深入理解FFmpeg閱讀體驗(yàn)》+ 書(shū)收到了,嶄新的開(kāi)篇

    今天收到了《深入理解FFmpeg》 嶄新的書(shū),一個(gè)在2022年較近距離接觸過(guò)卻尚未深入研究的領(lǐng)域圖像處理。最近剛好在作這方面的研究,希望自己可以把握這次機(jī)會(huì),好好學(xué)習(xí)下 FFMpeg,相信可以讓自己
    發(fā)表于 01-07 18:57

    如何進(jìn)行拷貝性能測(cè)試

    TogetherROS?·Bot拷貝性能測(cè)試 我們使用TogetherROS?·Bot系統(tǒng)內(nèi)部集成的性能測(cè)試工具——performance_test,來(lái)評(píng)估下開(kāi)啟
    的頭像 發(fā)表于 11-27 16:51 ?363次閱讀
    如何進(jìn)行<b class='flag-5'>零</b><b class='flag-5'>拷貝</b>性能測(cè)試

    什么是拷貝技術(shù)

    的應(yīng)用中,經(jīng)常會(huì)發(fā)生這種問(wèn)題,導(dǎo)致CPU都在做數(shù)據(jù)拷貝,沒(méi)有時(shí)間處理其他的應(yīng)用功能了,直接的感覺(jué)就是處理卡頓。 拷貝技術(shù) 針對(duì)這種問(wèn)題,
    的頭像 發(fā)表于 11-27 16:20 ?404次閱讀
    什么是<b class='flag-5'>零</b><b class='flag-5'>拷貝</b><b class='flag-5'>技術(shù)</b>

    《電子工程師必備——九大系統(tǒng)電路識(shí)圖寶典》+附錄2化整為和集為整電路分析方法

    編著的《電子工程師必備 九大系統(tǒng)電路識(shí)圖寶典第2版》! 通過(guò)閱讀附錄2的內(nèi)容,我對(duì)交流信號(hào)的頻段劃分和分析方法有了更深入理解。在電路分析中,對(duì)信號(hào)頻率的識(shí)別和理解是非常重要的,因?yàn)?/div>
    發(fā)表于 11-18 21:06

    【書(shū)籍評(píng)測(cè)活動(dòng)NO.25】深入理解FFmpeg,帶你FFmpeg從入門(mén)到精通

    這個(gè)領(lǐng)域。由劉歧牽頭編寫(xiě)的《深入理解FFmpeg》正是這樣一本好書(shū),值得向大家推薦。 ——楊成立,開(kāi)源項(xiàng)目SRS(Simple Realtime Server) 創(chuàng)始人、技術(shù)委員會(huì)成員 通過(guò)閱讀
    發(fā)表于 11-15 14:26

    傳統(tǒng)IO演化至拷貝的過(guò)程

    ,只是文件數(shù)據(jù)最終的去向仍然是本地磁盤(pán)還是網(wǎng)卡的區(qū)別,這里以socket文件為例介紹傳統(tǒng)IO演化至拷貝的過(guò)程。 介紹拷貝之前,可以先看一下傳統(tǒng)IO,借此熟悉一些相關(guān)概念,先上圖:
    的頭像 發(fā)表于 11-09 09:09 ?392次閱讀
    傳統(tǒng)IO演化至<b class='flag-5'>零</b><b class='flag-5'>拷貝</b>的過(guò)程

    深入理解TCP

    觸發(fā)超時(shí)重傳機(jī)制。 不同版本的操作系統(tǒng)可能超時(shí)時(shí)間不同,有的 1 秒的,也有 3 秒的,這個(gè)超時(shí)時(shí)間是寫(xiě)死在內(nèi)核里的,如果想要更改則需要重新編譯內(nèi)核,比較麻煩。 當(dāng)客戶(hù)端在 1 秒后沒(méi)收到服務(wù)端的 SYN-ACK 報(bào)文后,客戶(hù)端就會(huì)重發(fā) SYN 報(bào)文,那到底重發(fā)幾次呢? 在 Li
    的頭像 發(fā)表于 11-08 16:37 ?484次閱讀
    <b class='flag-5'>深入理解</b>TCP