从Linux零拷贝深入了解I/O

本文将从文件传输场景以及零拷贝技术深究 Linux I/O 的发展过程、优化手段以及实际应用。

前言

存储器是计算机的核心部件之一，在完全理想的状态下，存储器应该要同时具备以下三种特性：

• 速度足够快：存储器的存取速度应当快于 CPU 执行一条指令，这样 CPU 的效率才不会受限于存储器；
• 容量足够大：容量能够存储计算机所需的全部数据；
• 价格足够便宜：价格低廉，所有类型的计算机都能配备。

但是现实往往是残酷的，我们目前的计算机技术无法同时满足上述的三个条件，于是现代计算机的存储器设计采用了一种分层次的结构：

从顶至底，现代计算机里的存储器类型分别有：寄存器、高速缓存、主存和磁盘，这些存储器的速度逐级递减而容量逐级递增。

零拷贝direct I/O异步 I/O磁盘高速缓存区PageCacheTLB

I/OI/OI/O

时间花在cpu上更多就是cpu密集型，花在IO上多就是IO密集型

传统的 Linux 操作系统的标准 I/O 接口是基于数据拷贝操作的，即 I/O 操作会导致数据在操作系统内核地址空间的缓冲区和用户进程地址空间定义的缓冲区之间进行传输。设置缓冲区最大的好处是可以减少磁盘 I/O 的操作，如果所请求的数据已经存放在操作系统的高速缓冲存储器中，那么就不需要再进行实际的物理磁盘 I/O 操作；然而传统的 Linux I/O 在数据传输过程中的数据拷贝操作深度依赖 CPU，也就是说 I/O 过程需要 CPU 去执行数据拷贝的操作，因此导致了极大的系统开销，限制了操作系统有效进行数据传输操作的能力。

Linux I/O

基础知识

DMA

DMA，全称 Direct Memory Access，即直接存储器访问，是为了避免 CPU 在磁盘操作时承担过多的中断负载而设计的；在磁盘操作中，CPU 可将总线控制权交给 DMA 控制器，由 DMA 输出读写命令，直接控制 RAM 与 I/O 接口进行 DMA 传输，无需 CPU 直接控制传输，也没有中断处理方式那样保留现场和恢复现场过程，使得 CPU 的效率大大提高。

为什么要有DMA？

在没有 DMA 技术前，I/O 的过程是这样的：

• CPU 发出对应的指令给磁盘控制器，然后返回；
• 磁盘控制器收到指令后，于是就开始准备数据，会把数据放入到磁盘控制器的内部缓冲区中，然后产生一个中断；
• CPU 收到中断信号后，停下手头的工作，接着把磁盘控制器的缓冲区的数据一次一个字节地读进自己的寄存器，然后再把寄存器里的数据写入到内存，而在数据传输的期间 CPU 是被阻塞的状态，无法执行其他任务。

整个数据的传输过程，都要需要 CPU 亲自参与拷贝数据，而且这时 CPU 是被阻塞的；简单的搬运几个字符数据那没问题，但是如果我们用千兆网卡或者硬盘传输大量数据的时候，都用 CPU 来搬运的话，肯定忙不过来。

计算机科学家们发现了事情的严重性后，于是就发明了 DMA 技术，也就是直接内存访问（Direct Memory Access） 技术。

简单理解就是，在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情，这样 CPU 就可以去处理别的事务。

具体流程如下图：

• 用户进程调用 read 方法，向操作系统发出 I/O 请求，请求读取数据到自己的内存缓冲区中，进程进入阻塞状态；
• 操作系统收到请求后，进一步将 I/O 请求发送 DMA，释放 CPU；
• DMA 进一步将 I/O 请求发送给磁盘；
• 磁盘收到 DMA 的 I/O 请求，把数据从磁盘读取到磁盘控制器的缓冲区中，当磁盘控制器的缓冲区被读满后，向 DMA 发起中断信号，告知自己缓冲区已满；
• DMA 收到磁盘的信号，将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中，此时不占用 CPU，CPU 依然可以执行其它事务；
• 当 DMA 读取了足够多的数据，就会发送中断信号给 CPU；
• CPU 收到 中断信号，将数据从内核拷贝到用户空间，系统调用返回。

在有了 DMA 后，整个数据传输的过程，CPU 不再参与与磁盘交互的数据搬运工作，而是全程由 DMA 完成，但是 CPU 在这个过程中也是必不可少的，因为传输什么数据，从哪里传输到哪里，都需要 CPU 来告诉 DMA 控制器。

早期 DMA 只存在在主板上，如今由于 I/O 设备越来越多，数据传输的需求也不尽相同，所以每个 I/O 设备里面都有自己的 DMA 控制器。

MMU

Memory Management Unit，内存管理单元，主要实现：

• 竞争访问保护管理需求：需要严格的访问保护，动态管理哪些内存页/段或区，为哪些应用程序所用。这属于资源的竞争访问管理需求；
• 高效的翻译转换管理需求：需要实现快速高效的映射翻译转换，否则系统的运行效率将会低下；

Page Cache

32 KB

虚拟内存

在计算机领域有一句如同摩西十诫般神圣的哲言："计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决"，从内存管理、网络模型、并发调度甚至是硬件架构，都能看到这句哲言在闪烁着光芒，而虚拟内存则是这一哲言的完美实践之一。

虚拟内存为每个进程提供了一个一致的、私有且连续完整的内存空间；所有现代操作系统都使用虚拟内存，使用虚拟地址取代物理地址，主要有以下几点好处：

利用上述的第一条特性可以优化，可以把内核空间和用户空间的虚拟地址映射到同一个物理地址，这样在 I/O 操作时就不需要来回复制了。

• 多个虚拟内存可以指向同一个物理地址；
• 虚拟内存空间可以远远大于物理内存空间；
• 应用层面可管理连续的内存空间，减少出错。

NFS文件系统

网络文件系统是 FreeBSD 支持的文件系统中的一种，也被称为 NFS；NFS 允许一个系统在网络上与它人共享目录和文件，通过使用 NFS，用户和程序可以象访问本地文件 一样访问远端系统上的文件。

NFS协议和FTP协议：

• FTP协议：只能上传、下载，无法实现在线编辑等操作，安全性低，传输效率低，一般使用SFTP协议。
• NFS协议：协议简单，传输效率高，没有加密功能，安全性差。

Copy-on-write

写入时复制（Copy-on-write，COW）是一种计算机程序设计领域的优化策略。其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的。此作法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被创建，因此多个调用者只是读取操作时可以共享同一份资源。

问题和方法

传统文件传输的缺陷

有了 DMA 后，我们的磁盘 I/O 就一劳永逸了吗？并不是的；拿我们比较熟悉的下载文件举例，服务端要提供此功能，比较直观的方式就是：将磁盘中的文件读出到内存，再通过网络协议发送给客户端。

具体的 I/O 工作方式是，数据读取和写入是从用户空间到内核空间来回复制，而内核空间的数据是通过操作系统层面的 I/O 接口从磁盘读取或写入。

代码通常如下，一般会需要两个系统调用：

read(file, tmp_buf, len)
write(socket, tmp_buf, len)

代码很简单，虽然就两行代码，但是这里面发生了不少的事情：

这其中有：

read()write()

所以，要想提高文件传输的性能，就需要减少用户态与内核态的上下文切换和内存拷贝的次数。

如何优化传统文件传输

减少用户态与内核态的上下文切换

读取磁盘数据的时候，之所以要发生上下文切换，这是因为用户空间没有权限操作磁盘或网卡，内核的权限最高，这些操作设备的过程都需要交由操作系统内核来完成，所以一般要通过内核去完成某些任务的时候，就需要使用操作系统提供的系统调用函数。

而一次系统调用必然会发生 2 次上下文切换：首先从用户态切换到内核态，当内核执行完任务后，再切换回用户态交由进程代码执行。

减少数据拷贝次数

前面提到，传统的文件传输方式会历经 4 次数据拷贝；但很明显的可以看到：从内核的读缓冲区拷贝到用户的缓冲区和从用户的缓冲区里拷贝到 socket 的缓冲区」这两步是没有必要的。

因为在下载文件，或者说广义的文件传输场景中，我们并不需要在用户空间对数据进行再加工，所以数据并不需要回到用户空间中。

零拷贝

那么零拷贝技术就应运而生了，它就是为了解决我们在上面提到的场景——跨过与用户态交互的过程，直接将数据从文件系统移动到网络接口而产生的技术。

零拷贝实现原理

零拷贝技术实现的方式通常有 3 种：

• mmap + write
• sendfile
• splice

mmap + write

read()mmap()read()

buf = mmap(file, len)
write(sockfd, buf, len)

mmap

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);

mmap()

具体过程如下：

mmap()write()

mmap()read()

但这还不是最理想的零拷贝，因为仍然需要通过 CPU 把内核缓冲区的数据拷贝到 socket 缓冲区里，且仍然需要 4 次上下文切换，因为系统调用还是 2 次。

sendfile

sendfile()

#include <sys/socket.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

它的前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度。

read()write()

其次，该系统调用，可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里，不再拷贝到用户态，这样就只有 2 次上下文切换，和 3 次数据拷贝。如下图：

带有 scatter/gather 的 sendfile 方式

scatter/gatherCPU COPY

你可以在你的 Linux 系统通过下面这个命令，查看网卡是否支持 scatter-gather 特性：

$ ethtool -k eth0 | grep scatter-gather
scatter-gather: on

2.4sendfile()

• 第一步，通过 DMA 将磁盘上的数据拷贝到内核缓冲区里；
• 第二步，缓冲区描述符和数据长度传到 socket 缓冲区，这样网卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷贝到网卡的缓冲区里，此过程不需要将数据从操作系统内核缓冲区拷贝到 socket 缓冲区中，这样就减少了一次数据拷贝；

所以，这个过程之中，只进行了 2 次数据拷贝，如下图：

splice 方式

splicesendfilesendfilesplicesocketsocketsendfilesplicesendfilesendfilesplice

splice()Linuxpipe buffersplice()

splice()

pipe()pipe()splice()DMAsplice()splice()socketDMAsocketsplice()

splicesendfilesplice

sendfilesplice

零拷贝的实际应用

Kafka

事实上，Kafka 这个开源项目，就利用了「零拷贝」技术，从而大幅提升了 I/O 的吞吐率，这也是 Kafka 在处理海量数据为什么这么快的原因之一。

transferTo

@Overridepublic
long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {
    return fileChannel.transferTo(position, count, socketChannel);
}

sendfile()transferTo()sendfile()

Nginx

Nginx 也支持零拷贝技术，一般默认是开启零拷贝技术，这样有利于提高文件传输的效率，是否开启零拷贝技术的配置如下：

http {
...
    sendfile on
...
}

大文件传输场景

零拷贝还是最优选吗

在大文件传输的场景下，零拷贝技术并不是最优选择；因为在零拷贝的任何一种实现中，都会有「DMA 将数据从磁盘拷贝到内核缓存区——Page Cache」这一步，但是，在传输大文件（GB 级别的文件）的时候，PageCache 会不起作用，那就白白浪费 DMA 多做的一次数据拷贝，造成性能的降低，即使使用了 PageCache 的零拷贝也会损失性能。

这是因为在大文件传输场景下，每当用户访问这些大文件的时候，内核就会把它们载入 PageCache 中，PageCache 空间很快被这些大文件占满；且由于文件太大，可能某些部分的文件数据被再次访问的概率比较低，这样就会带来 2 个问题：

• PageCache 由于长时间被大文件占据，其他「热点」的小文件可能就无法充分使用到 PageCache，于是这样磁盘读写的性能就会下降了；
• PageCache 中的大文件数据，由于没有享受到缓存带来的好处，但却耗费 DMA 多拷贝到 PageCache 一次。

direct I/O

那么大文件传输场景下我们该选择什么方案呢？让我们先来回顾一下我们在文章开头介绍 DMA 时最早提到过的同步 I/O：

I/O

它把读操作分为两部分：

• 前半部分，内核向磁盘发起读请求，但是可以不等待数据就位就返回，于是进程此时可以处理其他任务；
• 后半部分，当内核将磁盘中的数据拷贝到进程缓冲区后，进程将接收到内核的通知，再去处理数据；

而且，我们可以发现，异步 I/O 并没有涉及到 PageCache；使用异步 I/O 就意味着要绕开 PageCache，因为填充 PageCache 的过程在内核中必须阻塞。

direct I/Obuffer I/O

direct I/O

direct I/O

direct I/O

• 内核的 I/O 调度算法会缓存尽可能多的 I/O 请求在 PageCache 中，最后「合并」成一个更大的 I/O 请求再发给磁盘，这样做是为了减少磁盘的寻址操作；
• 内核也会「预读」后续的 I/O 请求放在 PageCache 中，一样是为了减少对磁盘的操作；

实际应用中也有类似的配置，在 nginx 中，我们可以用如下配置，来根据文件的大小来使用不同的方式传输：

location /video/ {
    sendfile on;
    aio on;
    directio 1024m;
}

directio

使用 direct I/O 需要注意的点

Linus(Linus Torvalds)

"The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances." —Linus

Linus

man page

总结一下其中需要注意的点如下：

地址对齐限制

O_DIRECT会带来强制的地址对齐限制，这个对齐的大小也跟文件系统/存储介质相关，并且当前没有不依赖文件系统自身的接口提供指定文件/文件系统是否有这些限制的信息

blockdev --getss

blockdev --getpbsz

带来这个限制的原因也很简单，内存对齐这件小事通常是内核来处理的，而O_DIRECT绕过了内核空间，那么内核处理的所有事情都需要用户自己来处理，这里贴一篇详细解释。

O_DIRECT 平台不兼容

LinuxWindowsmacOS

不要并发地运行 fork 和 O_DIRECT I/O

O_DIRECT I/ObuffermmapO_DIRECT I/Ofork

以下情况这个限制不存在：

buffershmatmmapbuffermadvisebuffer

避免对同一文件混合使用 O_DIRECT 和普通 I/O

O_DIRECTI/OI/OI/O

direct I/Ommap。

NFS 协议下的 O_DIRECT

NFSO_DIRECTNFS

NFSO_DIRECT I/OPage CacheI/Ocache

I/OO_DIRECTI/OI/OI/O

LinuxNFS

在 Golang 中使用 direct I/O

direct io 必须要满足 3 种对齐规则：io 偏移扇区对齐，长度扇区对齐，内存 buffer 地址扇区对齐；前两个还比较好满足，但是分配的内存地址仅凭原生的手段是无法直接达成的。

posix_memalignGolang

Golang

buffer := make([]byte, 4096)

bufferdata

方法也很简单，就是先分配一个比预期要大的内存块，然后在这个内存块里找对齐位置 ；这是一个任何语言皆通用的方法，在 Go 里也是可用的。

比如，我现在需要一个 4096 大小的内存块，要求地址按照 512 对齐，可以这样做：

• 先分配 4096 + 512 大小的内存块，假设得到的内存块首地址是 p1；
• 然后在 [ p1, p1+512 ] 这个地址范围找，一定能找到 512 对齐的地址 p2；
• 返回 p2 ，用户能正常使用 [ p2, p2 + 4096 ] 这个范围的内存块而不越界。

以上就是基本原理了，具体实现如下：

// 从 block 首地址往后找到符合 AlignSize 对齐的地址并返回
// 这里很巧妙的使用了位运算，性能upup
func alignment(block []byte, AlignSize int) int {
   return int(uintptr(unsafe.Pointer(&block[0])) & uintptr(AlignSize-1))
}

// 分配 BlockSize 大小的内存块
// 地址按 AlignSize 对齐
func AlignedBlock(BlockSize int) []byte {
   // 分配一个大小比实际需要的稍大
   block := make([]byte, BlockSize+AlignSize)
   // 计算到下一个地址对齐点的偏移量
   a := alignment(block, AlignSize)
   offset := 0
   if a != 0 {
      offset = AlignSize - a
   }
   // 偏移指定位置，生成一个新的 block，这个 block 就满足地址对齐了
   block = block[offset : offset+BlockSize]
   if BlockSize != 0 {
      // 最后做一次地址对齐校验
      a = alignment(block, AlignSize)
      if a != 0 {
         log.Fatal("Failed to align block")
      }
   }
   return block
}

所以，通过以上 AlignedBlock 函数分配出来的内存一定是 512 地址对齐的，唯一的一点点缺点就是在分配较小内存块时对齐的额外开销显得比较大。

开源实现

Golang direct I/O

使用也很简单：

// 创建句柄
fp, err := directio.OpenFile(file, os.O_RDONLY, 0666)

// 创建地址按照 4k 对齐的内存块
buffer := directio.AlignedBlock(directio.BlockSize)
// 把文件数据读到内存块中
_, err := io.ReadFull(fp, buffer)

内核缓冲区和用户缓冲区之间的传输优化

zero-copyCPUsendfile()splice()

mmap

两种优化用户空间和内核空间数据传输的技术：

Copy-on-WriteBuffer Sharing

写时拷贝 (Copy-on-Write)

mmapCOW (Copy on Write)

COWMMUMMUMMUMMU

COWLinuxfork / cloneforkread-only

局限性

COWCOWCPU

此外，在实际应用的过程中，为了避免频繁的内存映射，可以重复使用同一段内存缓冲区，因此，你不需要在只用过一次共享缓冲区之后就解除掉内存页的映射关系，而是重复循环使用，从而提升性能。

read-onywrite-only

COW 的实际应用

Redis 的持久化机制

Redis

RedisbgsavebgrewriteaofRedisCOWfork()

语言层面的应用

C++ 98std::string

std::string x("Hello");
std::string y = x;  // x、y 共享相同的 buffer
y += ", World!";    // 写时复制，此时 y 使用一个新的 buffer
                    // x 依然使用旧的 buffer

Golangstring, sliceappendcopyappend

缓冲区共享 (Buffer Sharing)

Linux I/OI/Oread()write()

I/OLinuxI/OMMUTLBI/OTLBI/O

Fast Buffersfbuffbufsfbufsbuffer poolfbufs

共享缓冲区技术的实现需要依赖于用户进程、操作系统内核、以及 I/O 子系统 (设备驱动程序，文件系统等)之间协同工作。比如，设计得不好的用户进程容易就会修改已经发送出去的 fbuf 从而污染数据，更要命的是这种问题很难 debug。虽然这个技术的设计方案非常精彩，但是它的门槛和限制却不比前面介绍的其他技术少：首先会对操作系统 API 造成变动，需要使用新的一些 API 调用，其次还需要设备驱动程序配合改动，还有由于是内存共享，内核需要很小心谨慎地实现对这部分共享的内存进行数据保护和同步的机制，而这种并发的同步机制是非常容易出 bug 的从而又增加了内核的代码复杂度，等等。因此这一类的技术还远远没有到发展成熟和广泛应用的阶段，目前大多数的实现都还处于实验阶段。

总结

I/ODMACPUI/O

Zero-copyCPU

零拷贝技术的文件传输方式相比传统文件传输的方式，减少了 2 次上下文切换和数据拷贝次数，只需要 2 次上下文切换和数据拷贝次数，就可以完成文件的传输，而且 2 次的数据拷贝过程，都不需要通过 CPU，2 次都是由 DMA 来搬运。

总体来看，零拷贝技术至少可以把文件传输的性能提高一倍以上，以下是各方案详细的成本对比：

CPU 拷贝	DMA 拷贝	系统调用	上下文切换	硬件依赖	支持任意类型输入/输出描述符
传统方法	2	2	read/write	4	否	是
内存映射	1	2	mmap/write	4	否	是
sendfile	1	2	sendfile	2	否	否
sendfile(scatter/gather copy)	0	2	sendfile	2	是	否
splice	0	2	splice	2	否	是

PageCachePageCacheI/OI/O

PageCachePageCacheI/Odirect I/Odirect I/OLinus

而在更广泛的场景下，我们还需要注意到内核缓冲区和用户缓冲区之间的传输优化，这种方式侧重于在用户进程的缓冲区和操作系统的页缓存之间的 CPU 拷贝的优化，延续了以往那种传统的通信方式，但更灵活。

I/O

逐渐看不懂了，后面再学习吧～