Linux系统I/O操作与零拷贝

Posted 2023-04-19

参考技术A

Linux中传统的I/O操作是一种缓存I/O，I/O过程中产生的数据传输通常需要在缓冲区中进行多次拷贝。当应用程序需要访问某个数据（read()操作）时，操作系统会先判断这块数据是否在内核缓冲区中，如果在内核缓冲区中找不到这块数据，内核会先将这块数据从磁盘中读出来放到内核缓冲区中，应用程序再从缓冲区中读取。当应用程序需要将数据输出（write()）时，同样需要先将数据拷贝到输出堆栈相关的内核缓冲区，再从内核缓冲区拷贝到输出设备中。

以一次网络请求为例，如下图。对于一次数据读取，用户应用程序只需要调用read（）及write（）两个系统调用就可以完成一次数据传输，但这个过程中数据经过了四次拷贝，且数据拷贝需要由CPU来调控。在某些情况下，这些数据拷贝会极大地降低系统数据传输的性能，比如文件服务器中，一个文件从磁盘读取后不加修改地回传给调用方，那么这占用CPU时间去处理这四次数据拷贝的性价比是极低的。

一次处理网络调用的系统I/O的流程：

以上可以发现，传统的Linux系统I/O 操作要进行4次内核空间与应用程序空间的上下文切换，以及4次数据拷贝。

直接内存访问（Direct Memory Access，DMA）是计算机科学中的一种内存访问技术，允许某些电脑内部的硬件子系统独立地读取系统内存，而不需要中央处理器（CPU）的介入。在同等程度的处理器负担下，DMA是一种快速的数据传送方式。这类子系统包括硬盘控制器、显卡、网卡和声卡。

在Linux系统中，当应用程序需要读取文件中的数据时，操作系统先分配一些内存，将数据从存储设备读入到这些内存中，然后再将数据传递应用进程；当需要往文件中写数据时，操作系统先分配内存接收用户数据，然后再将数据从内存写入磁盘。文件cache管理就是对这些由操作系统分配并用开存储文件数据的内存的管理。

在Linux系统中，文件cache分为两个层面，page cache 与 Buffer cache，每个page cache包含若干个buffer cache。操作系统中，磁盘文件都是由一系列的数据块（Block）组成，buffer cache也叫块缓存，是对磁盘一个数据块的缓存，目的是为了在程序多次访问同一个磁盘块时减少访问时间；而文件系统对数据的组织形式为页，page cache为页缓存，是由多个块缓存构成，其对应的缓存数据块在磁盘上不一定是连续的。也就是说buffer cache缓存文件的具体内容--物理磁盘上的磁盘块，加速对磁盘的访问，而page cache缓存文件的逻辑内容，加速对文件内容的访问。

buffer cache的大小一般为1k，page cache在32位系统上一般为4k，在64位系统上一般为8k。磁盘数据块、buffer cache、page cache及文件的关系如下图：

文件cache的目的是加快对数据文件的访问，同时会有一个预读过程。对于每个文件的第一次读请求，系统会读入所请求的页面并读入紧随其后的几个页面；对于第二次读请求，如果所读页面在cache中，则会直接返回，同时又一个异步预读的过程（将读取页面的下几页读入cache中），如果不在cache中，说明读请求不是顺序读，则会从磁盘中读取文件内容并刷新cache。因此在顺序读取情况下，读取数据的性能近乎内存读取。

DMA允许硬件子系统直接将数据从磁盘读取到内核缓冲区，那么在一次数据传输中，磁盘与内核缓冲区，输出设备与内核缓冲区之间的两次数据拷贝就不需要CPU进行调度，CPU只需要进行缓冲区管理、以及创建和处理DMA。而Page Cache/Buffer Cache的预读取机制则加快了数据的访问效率。如下图所示，还是以文件服务器请求为例，此时CPU负责的数据拷贝次数减少了两次，数据传输性能有了较大的提高。

使用DMA的系统I/O操作要进行4次内核空间与应用程序空间的上下文切换，2次CPU数据拷贝及2次DMA数据拷贝。

Mmap内存映射与标准I/O操作的区别在于当应用程序需要访问数据时，不需要进行内核缓冲区到应用程序缓冲区之间的数据拷贝。Mmap使得应用程序和操作系统共享内核缓冲区，应用程序直接对内核缓冲区进行读写操作，不需要进行数据拷贝。Linux系统中通过调用mmap()替代read()操作。

同样以文件服务器获取文件（不加修改）为例，通过mmap操作的一次系统I/O过程如下：

通过以上流程可以看到，数据拷贝从原来的4次变为3次，2次DMA拷贝1次内核空间数据拷贝，CPU只需要调控1次内核空间之间的数据拷贝，CPU花费在数据拷贝上的时间进一步减少（4次上下文切换没有改变）。对于大容量文件读写，采用mmap的方式其读写效率和性能都比较高。（数据页较多，需要多次拷贝）

注：mmap()是让应用程序空间与内核空间共享DMA从磁盘中读取的文件缓冲，也就是应用程序能直接读写这部分PageCache，至于上图中从页缓存到socket缓冲区的数据拷贝只是文件服务器的处理，根据应用程序的不同会有不同的处理，应用程序也可以读取数据后进行修改。重点是虚拟内存映射，内核缓存共享。

djk中nio包下的MappedByteBuffer，官方注释为 A direct byte buffer whose content is a memory-mapped region of a file，即直接字节缓冲区，其内容是文件的内存映射区域。 FileChannel是是nio操作文件的类，其map()方法在在实现类中调用native map0()本地方法，该方法通过mmap()实现，因此是将文件从磁盘读取到内核缓冲区，用户应用程序空间直接操作内核空间共享的缓冲区，Java程序通过MappedByteBuffer的get()方法获取内存数据。

MappedByteBuffer允许Java程序直接从内存访问文件，可以将整个文件或文件的一部分映射到内存中，由操作系统进行相关的请求并将内存中的修改写入到磁盘中。

FileChannel map有三种模式

MappedByteBuffer的应用，以rocketMQ为例（简单介绍）。

producer端发送消息最终会被写入到commitLog文件中，consumer端消费时先从订阅的consumeQueue中读取持久化消息的commitLogOffset、size等内容，随后再根据offset、size从commitLog中读取消息的真正实体内容。其中，commitLog是混合部署的，所有topic下的消息队列共用一个commitLog日志数据文件，consumeQueue类似于索引，同时区分开不同topic下不同MessageQueue的消息。

rocketMQ利用MappedByteBuffer及PageCache加速对持久化文件的读写操作。rocketMQ通过MappedByteBuffer将日志数据文件映射到OS的虚拟内存中（PageCache）,写消息时首先写入PageCache，通过刷盘方式（异步或同步）将消息批量持久化到磁盘；consumer消费消息时，读取consumeQueue是顺序读取的，虽然有多个消费者操作不同的consumeQueue，对混合部署的commitLog的访问时随机的，但整体上是从旧到新的有序读，加上PageCache的预读机制，大部分情况下消息还是从PageCache中读取，不会产生太多的缺页中断（要读取的消息不在pageCache中）而从磁盘中读取。

rocketMQ利用mmap()使程序与内核空间共享内核缓冲区，直接对PageCache中的文件进行读写操作，加速对消息的读写请求，这是其高吞吐量的重要手段。

使用mmap能减少CPU数据拷贝的次数，但也存在一些问题。

从Linux2.1开始，Linux引入sendfile()简化操作。取消read()/write()，mmap()/write()。

调用sendfile的流程如下：

通过sendfile()的I/O进行了2次应用程序空间与内核空间的上下文切换，以及3次数据拷贝，其中2次是DMA拷贝，1次是CPU拷贝。sendfile相比起mmap，数据信息没有进入到应用程序空间，所以能减少2次上下文切换的开销，而数据拷贝次数是一样的。

上述流程也可以看出，sendfile()适合对文件不加修改的I/O操作。

sendfile()只是减少应用程序空间与内核空间的上下文切换，并没有减少CPU数据拷贝的次数，还存在一次内核空间的两个缓冲区的数据拷贝。要实现CPU零数据拷贝，需要引入一些硬件上的支持。在上一小节的sendfile流程中，数据需要从内核缓冲区拷贝到内核空间socket缓冲区，数据都是在内核空间，如果socket缓冲区到网卡的这次DMA数据传输操作能直接读取到内核缓冲区中的数据，那么这一次的CPU数据拷贝也就能避免。要达到这个目的，DMA需要知道存有文件位置和长度信息的缓冲区描述符，即socket缓冲区需要从内核缓冲区接收这部分信息，DMA需要支持数据收集功能。

sendfile()调用后，数据从磁盘文件拷贝到内核缓冲区中，然后将文件位置和长度信息的缓冲区描述符传递到socket缓冲区，此时数据并没有被拷贝。之后网卡子系统根据socket缓冲区中的文件信息利用DMA技术收集拷贝数据。整个过程进行了2次内核空间和应用程序空间的上下文切换，及2次DMA数据拷贝，CPU不需要参与数据拷贝工作，从而实现零拷贝。当然DMA收集拷贝功能需要硬件和驱动程序的支持。

在操作系统中，硬件和软件之间的数据传输可以通过DMA来进行，DMA进行数据传输的过程几乎不需要CPU参与，但是在内核缓冲区（页缓存）与应用程序缓冲区之间的数据拷贝并没有类似于DMA之类的工具可以使用，mmap、sendfile都是为了减少数据在内核空间与应用程序空间传输时的数据拷贝和上下文切换次数，有效地改善数据在两者之间传递的效率。

linux操作系统的零拷贝技术并不单指某一种方式，现有的零拷贝技术种类非常多，在不同的Linux内核版本上有不同的支持。常见的，如果应用程序需要修改数据，则使用mmap()，如果只进行文件数据传输，则可选择sendfile()。

另外，关于零拷贝技术适用于什么场景？在上述的描述中，数据在传递过程中，除了mmap外，应用程序和操作系统几乎是没有改变数据的，mmap的内存映射也是没有改变数据的，也就是说在静态资源的读取场景下，零拷贝更能发挥作用。正如其名，拷贝是在不改变数据的情况下，零是利用手段去减少CPU参与数据拷贝的次数，以释放CPU去进行其他系统调用与计算。

零拷贝原理详解

引言

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

零拷贝（ zero-copy ）技术可以有效地改善数据传输的性能，在内核驱动程序（比如网络堆栈或者磁盘存储驱动程序）处理 I/O 数据的时候，零拷贝技术可以在某种程度上减少甚至完全避免不必要 CPU 数据拷贝操作。

零拷贝概念

零拷贝就是一种避免 CPU 将数据从一块存储拷贝到另外一块存储的技术。针对操作系统中的设备驱动程序、文件系统以及网络协议堆栈而出现的各种零拷贝技术极大地提升了特定应用程序的性能，并且使得这些应用程序可以更加有效地利用系统资源。这种性能的提升就是通过在数据拷贝进行的同时，允许 CPU 执行其他的任务来实现的。

零拷贝技术可以减少数据拷贝和共享总线操作的次数，消除传输数据在存储器之间不必要的中间拷贝次数，从而有效地提高数据传输效率。而且，零拷贝技术减少了用户应用程序地址空间和操作系统内核地址空间之间因为上下文切换而带来的开销。进行大量的数据拷贝操作其实是一件简单的任务，从操作系统的角度来说，如果 CPU 一直被占用着去执行这项简单的任务，那么这将会是很浪费资源的；如果有其他比较简单的系统部件可以代劳这件事情，从而使得 CPU 解脱出来可以做别的事情，那么系统资源的利用则会更加有效。综上所述，零拷贝技术的目标可以概括如下：

1. 避免数据拷贝
   ①避免操作系统内核缓冲区之间进行数据拷贝操作。
   ②避免操作系统内核和用户应用程序地址空间这两者之间进行数据拷贝操作。
   ③用户应用程序可以避开操作系统直接访问硬件存储。
   ④数据传输尽量让 DMA 来做。
2. 综合目标
   ①避免不必要的系统调用和上下文切换。
   ②需要拷贝的数据可以先被缓存起来。
   ③对数据进行处理尽量让硬件来做。

场景

接下来就探讨Linux中主要的几种零拷贝技术以及零拷贝技术适用的场景。为了迅速建立起零拷贝的概念，我们拿一个常用的场景进行引入
在写一个服务端程序时（Web Server或者文件服务器），文件下载是一个基本功能。这时候服务端的任务是：将服务端主机磁盘中的文件不做修改地从已连接的socket发出去，我们通常用下面的代码完成：

1. while((n = read(diskfd, buf, BUF_SIZE)) > 0)

2. write(sockfd, buf , n);

基本操作就是循环的从磁盘读入文件内容到缓冲区，再将缓冲区的内容发送到socket。但是由于Linux的I/O操作默认是缓冲I/O。这里面主要使用的也就是read和write两个系统调用，我们并不知道操作系统在其中做了什么。实际上在以上I/O操作中，发生了多次的数据拷贝。
当应用程序访问某块数据时，操作系统首先会检查，是不是最近访问过此文件，文件内容是否缓存在内核缓冲区，如果是，操作系统则直接根据read系统调用提供的buf地址，将内核缓冲区的内容拷贝到buf所指定的用户空间缓冲区中去。如果不是，操作系统则首先将磁盘上的数据拷贝的内核缓冲区，这一步目前主要依靠DMA来传输，然后再把内核缓冲区上的内容拷贝到用户缓冲区中。接下来，write系统调用再把用户缓冲区的内容拷贝到网络堆栈相关的内核缓冲区中，最后socket再把内核缓冲区的内容发送到网卡上。
说了这么多，不如看图清楚：

 多次数据拷贝

从上图中可以看出，共产生了四次数据拷贝，即使使用了DMA来处理了与硬件的通讯，CPU仍然需要处理两次数据拷贝，与此同时，在用户态与内核态也发生了多次上下文切换，无疑也加重了CPU负担。
在此过程中，我们没有对文件内容做任何修改，那么在内核空间和用户空间来回拷贝数据无疑就是一种浪费，而零拷贝主要就是为了解决这种低效性。

零拷贝技术（zero-copy）

零拷贝主要的任务就是避免CPU将数据从一块存储拷贝到另外一块存储，主要就是利用各种零拷贝技术，避免让CPU做大量的数据拷贝任务，减少不必要的拷贝，或者让别的组件来做这一类简单的数据传输任务，让CPU解脱出来专注于别的任务。这样就可以让系统资源的利用更加有效。
我们继续回到引文中的例子，我们如何减少数据拷贝的次数呢？一个很明显的着力点就是减少数据在内核空间和用户空间来回拷贝，这也引入了零拷贝的一个类型：让数据传输不需要经过user space

使用mmap

我们减少拷贝次数的一种方法是调用mmap()来代替read调用：

1. buf = mmap(diskfd, len);

2. write(sockfd, buf, len);

应用程序调用mmap()，磁盘上的数据会通过DMA被拷贝的内核缓冲区，接着操作系统会把这段内核缓冲区与应用程序共享，这样就不需要把内核缓冲区的内容往用户空间拷贝。应用程序再调用write(),操作系统直接将内核缓冲区的内容拷贝到socket缓冲区中，这一切都发生在内核态，最后，socket缓冲区再把数据发到网卡去。同样的，看图很简单：

 mmap

使用mmap替代read很明显减少了一次拷贝，当拷贝数据量很大时，无疑提升了效率。但是使用mmap是有代价的。当你使用mmap时，你可能会遇到一些隐藏的陷阱。例如，当你的程序map了一个文件，但是当这个文件被另一个进程截断(truncate)时, write系统调用会因为访问非法地址而被SIGBUS信号终止。SIGBUS信号默认会杀死你的进程并产生一个coredump,如果你的服务器这样被中止了，那会产生一笔损失。
通常我们使用以下解决方案避免这种问题：

1. 为SIGBUS信号建立信号处理程序
   当遇到SIGBUS信号时，信号处理程序简单地返回，write系统调用在被中断之前会返回已经写入的字节数，并且errno会被设置成success,但是这是一种糟糕的处理办法，因为你并没有解决问题的实质核心。
2. 使用文件租借锁
   通常我们使用这种方法，在文件描述符上使用租借锁，我们为文件向内核申请一个租借锁，当其它进程想要截断这个文件时，内核会向我们发送一个实时的RT_SIGNAL_LEASE信号，告诉我们内核正在破坏你加持在文件上的读写锁。这样在程序访问非法内存并且被SIGBUS杀死之前，你的write系统调用会被中断。write会返回已经写入的字节数，并且置errno为success。
   我们应该在mmap文件之前加锁，并且在操作完文件后解锁：

if(fcntl(diskfd, F_SETSIG, RT_SIGNAL_LEASE) == -1)

        perror("kernel lease set signal");

        return -1;

/* l_type can be F_RDLCK F_WRLCK 加锁*/

/* l_type can be F_UNLCK 解锁*/

        if(fcntl(diskfd, F_SETLEASE, l_type))

        perror("kernel lease set type");

        return -1;

使用sendfile

从2.1版内核开始，Linux引入了sendfile来简化操作:

#include<sys/sendfile.h>

ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

系统调用sendfile()在代表输入文件的描述符in_fd和代表输出文件的描述符out_fd之间传送文件内容（字节）。描述符out_fd必须指向一个套接字，而in_fd指向的文件必须是可以mmap的。这些局限限制了sendfile的使用，使sendfile只能将数据从文件传递到套接字上，反之则不行。使用sendfile不仅减少了数据拷贝的次数，还减少了上下文切换，数据传送始终只发生在kernel space。

在我们调用sendfile时，如果有其它进程截断了文件会发生什么呢？假设我们没有设置任何信号处理程序，sendfile调用仅仅返回它在被中断之前已经传输的字节数，errno会被置为success。如果我们在调用sendfile之前给文件加了锁，sendfile的行为仍然和之前相同，我们还会收到RT_SIGNAL_LEASE的信号。
目前为止，我们已经减少了数据拷贝的次数了，但是仍然存在一次拷贝，就是页缓存到socket缓存的拷贝。那么能不能把这个拷贝也省略呢？
借助于硬件上的帮助，我们是可以办到的。之前我们是把页缓存的数据拷贝到socket缓存中，实际上，我们仅仅需要把缓冲区描述符传到socket缓冲区，再把数据长度传过去，这样DMA控制器直接将页缓存中的数据打包发送到网络中就可以了。
总结一下，sendfile系统调用利用DMA引擎将文件内容拷贝到内核缓冲区去，然后将带有文件位置和长度信息的缓冲区描述符添加socket缓冲区去，这一步不会将内核中的数据拷贝到socket缓冲区中，DMA引擎会将内核缓冲区的数据拷贝到协议引擎中去，避免了最后一次拷贝。不过这一种收集拷贝功能是需要硬件以及驱动程序支持的。

 带DMA的sendfile

使用splice

sendfile只适用于将数据从文件拷贝到套接字上，限定了它的使用范围。Linux在2.6.17版本引入splice系统调用，用于在两个文件描述符中移动数据：

#define _GNU_SOURCE /* See feature_test_macros(7) */

#include <fcntl.h>

ssize_t splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out, size_t len, unsigned int flags);

splice调用在两个文件描述符之间移动数据，而不需要数据在内核空间和用户空间来回拷贝。他从fd_in拷贝len长度的数据到fd_out，但是有一方必须是管道设备，这也是目前splice的一些局限性。flags参数有以下几种取值：
1.SPLICE_F_MOVE ：尝试去移动数据而不是拷贝数据。这仅仅是对内核的一个小提示：如果内核不能从pipe移动数据或者pipe的缓存不是一个整页面，仍然需要拷贝数据。Linux最初的实现有些问题，所以从2.6.21开始这个选项不起作用，后面的Linux版本应该会实现。

1. SPLICE_F_NONBLOCK ：splice 操作不会被阻塞。然而，如果文件描述符没有被设置为不可被阻塞方式的 I/O ，那么调用 splice 有可能仍然被阻塞。
2. SPLICE_F_MORE： 后面的splice调用会有更多的数据。
   splice调用利用了Linux提出的管道缓冲区机制， 所以至少一个描述符要为管道。
   以上几种零拷贝技术都是减少数据在用户空间和内核空间拷贝技术实现的，但是有些时候，数据必须在用户空间和内核空间之间拷贝。这时候，我们只能针对数据在用户空间和内核空间拷贝的时机上下功夫了。Linux通常利用写时复制(copy on write)来减少系统开销，这个技术又时常称作COW。

作者：Alfie20
链接：https://www.jianshu.com/p/580a14db9d77
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。