数据的四次拷贝与四次上下文切换

很多应用程序在面临客户端请求时，可以等价为进行如下的系统调用：

File.read(file, buf, len);

Socket.send(socket, buf, len);

例如消息中间件 Kafka 就是这个应用场景，从磁盘中读取一批消息后原封不动地写入网卡（NIC，Network interface controller）进行发送。

在没有任何优化技术使用的背景下，操作系统为此会进行 4 次数据拷贝，以及 4 次上下文切换，如下图所示：

a5efa2eef8719df1ab75236a96467835_640_wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1.jpg

如果没有优化，读取磁盘数据，再通过网卡传输的场景性能比较差：

4 次 copy：

CPU 负责将数据从磁盘搬运到内核空间的 Page Cache 中；

CPU 负责将数据从内核空间的 Socket 缓冲区搬运到的网络中；

CPU 负责将数据从内核空间的 Page Cache 搬运到用户空间的缓冲区；

CPU 负责将数据从用户空间的缓冲区搬运到内核空间的 Socket 缓冲区中；

4 次上下文切换：

read 系统调用时：用户态切换到内核态；

read 系统调用完毕：内核态切换回用户态；

write 系统调用时：用户态切换到内核态；

write 系统调用完毕：内核态切换回用户态；

我们不免发出抱怨：

CPU 全程负责内存内的数据拷贝还可以接受，因为效率还算可以接受，但是如果要全程负责内存与磁盘、网络的数据拷贝，这将难以接受，因为磁盘、网卡的速度远小于内存，内存又远远小于 CPU；
4 次 copy 太多了，4 次上下文切换也太频繁了；

DMA 参与下的数据四次拷贝

0a3a81e68d5629e7caf64a98f716e3e5_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png

DMA 技术很容易理解，本质上，DMA 技术就是我们在主板上放一块独立的芯片。
在进行内存和 I/O 设备的数据传输的时候，我们不再通过 CPU 来控制数据传输，而直接通过 DMA 控制器（DMA Controller，简称 DMAC），这块芯片，我们可以认为它其实就是一个协处理器（Co-Processor）。

DMAC 最有价值的地方体现在当我们要传输的数据特别大、速度特别快，或者传输的数据特别小、速度特别慢的时候。

比如说，我们用千兆网卡或者硬盘传输大量数据的时候，如果都用 CPU 来搬运的话，肯定忙不过来，所以可以选择 DMAC。而当数据传输很慢的时候，DMAC 可以等数据到齐了，再发送信号，给到 CPU 去处理，而不是让 CPU 在那里忙等待。

注意，这里面的“协”字。
DMAC 是在“协助”CPU，完成对应的数据传输工作。
在 DMAC 控制数据传输的过程中，我们还是需要 CPU 的进行控制，但是具体数据的拷贝不再由 CPU 来完成。

原本，计算机所有组件之间的数据拷贝（流动）必须经过 CPU，如下图所示：