0%

零拷贝

本文翻译自:Zero Copy I: User-Mode Perspective
本文解释了Linux的零拷贝作用是什么,为什么它非常有用和在哪些地方可以使用该功能。

到目前为止,几乎每个人都听说过在Linux下的所谓的零拷贝功能,但我经常遇到对这个主题没有完全理解的人。 正因为如此,我决定写一些文章,深入探讨这件事,希望揭开这个有用的功能。 在本文中,我们从用户应用程序的角度看待零拷贝,因此故意省略了内核级别的详细信息。

零拷贝是什么

为了更好地理解问题的解决方案,我们首先需要了解问题本身。 让我们看看一个网络服务器通过网络将存储在文件中的数据提供给客户端这个简单过程中涉及的内容,。 以下是一些示例代码:

1
2
read(file, tmp_buf, len);
write(socket, tmp_buf, len);

看起来很简单, 你会认为只有两个系统调用并不会有太多的开销。 而然现实中这可能远离真相。 在这两个系统调用之后,数据已经被复制了至少四次,并且几乎执行了同样次数的用户/内核空间的上下文切换。(实际上这个过程要复杂得多,但我想保持简单)。 要更好地了解这些系统调用所涉及的处理过程,请参见图1。 顶部显示上下文切换,底部显示拷贝操作。
系统调用拷贝过程
图一: 两个系统调用中的拷贝过程

第一步:read系统调用导致上下文从用户模式切换到内核模式。第一个副本由DMA引擎执行,DMA引擎从磁盘读取文件内容并将它们存储到内核地址空间缓冲区中。

第二步:将数据从内核缓冲区复制到用户缓冲区,并且read系统调用返回。read调用返回导致上下文从内核切换回用户模式。现在数据存储在用户地址空间缓冲区中。

第三步:write系统调用导致上下文从用户模式切换到内核模式。执行第三次复制,以再次将数据放入内核地址空间缓冲区。这个时候,数据被放入一个不同的缓冲区,一个与sockets相关联的缓冲区。

第四步:写系统调用返回,创建我们的第四个上下文切换。独立和异步地,当DMA引擎将数据从内核缓冲区传递到协议引擎时,发生第四次复制。你可能问自己:独立和异步这是什么意思?难道是调用会在数据被传输前返回? 事实上调用返回并不保证数据被传输;它甚至不保证传输的开始。它只是意味着以太网驱动程序在其队列中有空闲描述符,并接受我们的数据进行传输。在我们之前可能有许多数据包在排队。除非驱动器或硬件实现优先级环或队列,否则数据是以先进先出的方式传输的。 (图1中的DMA拷贝说明了最后一个数据拷贝可以被延迟的事实)。

正如你所看到的,很多数据复制操作并不是真正需要的。 可以消除一些复制操作以减少开销并提高性能。 作为驱动程序开发人员,我会和一些具有非常先进功能的硬件打交道。 某些硬件可以完全绕过主存储器,并将数据直接传输到另一个设备。 这个功能减少了一次系统内存的复制操作,是一个很好的功能,但并不是所有的硬件都支持。 还存在必须将来自硬盘的数据针对网络传输重新打包的问题,这引入了一些复杂性。 为了降低开销,我们可以通过消除内核和用户缓冲区之间的一些复制来开始。

mmap

消除复制的一种方法是调用mmap来替代read。 例如:

1
2
tmp_buf = mmap(file, len);
write(socket, tmp_buf, len);

为了更好的理解处理过程,请看下图:上下文切换是一样的。
调用mmap
图2. 调用 mmap

第一步:mmap系统调用导致DMA引擎将文件内容复制到内核缓冲区中。然后与用户进程共享缓冲区,而不在内核和用户存储器空间之间执行任何复制。

第二步:write系统调用导致内核将数据从原始内核缓冲区复制到与套接字相关联的内核缓冲区中。

第三步:当DMA引擎将数据从内核套接字缓冲区传递到协议引擎时,发生第三次复制。

通过使用mmap而不是read,我们已经削减了一半的内核必须复制的数据量。当传输大量数据时,这产生相当好的结果。然而,这种改进不是没有代价的;使用mmap + write方法时存在隐藏的缺陷。当内存映射一个文件,然后调用write,而另一个进程截断同一个文件,你会陷入其中之一。您的写系统调用将由总线错误信号SIGBUS中断,因为您执行了错误的存储器访问。该信号的默认行为是杀死进程和转储核心,这不是网络服务器最理想的操作。有两种方法来解决这个问题。

第一种方法是为SIGBUS信号安装一个信号处理程序,然后在处理程序中调用return。通过这样做,写系统调用返回其中断之前写入的字节数,并将errno设置为success。让我指出,这将是一个坏的解决方案,一个解决问题表象而不是问题根本发送原因的方案。因为SIGBUS表明已经发生了非常严重的错误,我不鼓励使用这个解决方案。

第二个解决方案涉及内核中的文件租赁(在Microsoft Windows中称为“机会锁定”)。 这是解决这个问题的正确方法。 通过对文件描述符使用租赁,您可以在特定文件上使用内核租用。 然后,您可以从内核请求读/写租赁。 当另一个进程尝试截断要发送的文件时,内核会向您发送一个实时信号RT_SIGNAL_LEASE信号。 它告诉你内核正在中断你的写入或读取租赁该文件。 您的写调用在程序访问无效地址并被SIGBUS信号终止之前中断。 写调用的返回值是在中断之前写入的字节数,并且errno将设置为success。 这里是一些示例代码,显示如何从内核获取租约:

1
2
3
4
5
6
7
8
9
if(fcntl(fd, F_SETSIG, RT_SIGNAL_LEASE) == -1) {
perror("kernel lease set signal");
return -1;
}
/* l_type can be F_RDLCK F_WRLCK */
if(fcntl(fd, F_SETLEASE, l_type)){
perror("kernel lease set type");
return -1;
}

你应该在mmapping文件之前得到你的租赁,并在你完成后打破租约。 这通过调用具有租用类型F_UNLCK的fcntl F_SETLEASE实现。

Sendfile

在内核版本2.1中,引入了sendfile系统调用,以简化网络上和两个本地文件之间的数据传输。 sendfile的引入不仅减少了数据复制,还减少了上下文切换。 使用如下:

1
sendfile(socket, file, len);

为了更好的理解sendfile调用的处理过程请看图3:
图 3. 使用sendfile替代read,write
6345f3
第一步:sendfile系统调用导致文件内容被DMA引擎复制到内核缓冲区中。 然后内核将数据复制到与套接字相关联的内核缓冲区中。

第二步:当DMA引擎将数据从内核套接字缓冲区传递到协议引擎时,发生第三次复制。

你可能想知道如果另一个进程截断我们用sendfile系统调用发送的文件会发生什么。 如果我们不注册任何信号处理程序,sendfile调用只是返回它在被中断前传输的字节数并且errno将被设置为成功。

然而,如果我们在调用sendfile之前从内核中获得文件的租约,则行为和返回状态完全相同。 我们还会在sendfile调用返回之前获取RT_SIGNAL_LEASE信号。

到目前为止,我们已经能够避免一些内核复制操作,但是我们仍然有一次内核复制操作。 这也可以避免吗? 当然,这需要硬件的一点帮助。 为了消除内核所做的所有数据复制,我们需要一个支持聚集操作的网络接口。 这仅仅意味着等待传输的数据不需要在连续的内存空间中; 这些数据可以分散在存储器的各个位置。 在内核版本2.4中,修改了套接字缓冲区描述符以适应这些要求-在Linux下称为零拷贝。 这种方法不仅减少了多个上下文切换,还完全消除了处理器的数据复制操作。 对于用户级应用程序没有什么改变,所以代码看起来像这样:

1
sendfile(socket, file, len);

为了更好的理解sendfile调用的处理过程请看图4:
6345f4
图 4. 支持聚集操作的硬件从内存的多个位置获取数据,消除内存拷贝

第一步:sendfile系统调用导致文件内容被DMA引擎复制到内核缓冲区中。

第二步:没有数据被复制到套接字缓冲区。相反,只有关于数据的位置和长度的信息的描述符附加到套接字缓冲区。 DMA引擎将数据直接从内核缓冲区传递到协议引擎,从而消除最后剩下的一次内存拷贝。

因为数据实际上仍然是从磁盘复制到内存和从内存到电线,有些人可能认为这不是一个真正的零复制。但是,从操作系统的角度来看,这是零拷贝,因为数据不会在内核缓冲区之间来回拷贝。当使用零拷贝时,除了避免拷贝之外,还可以有其他性能优势,例如较少的上下文切换,较少的CPU缓存数据污染和没有CPU计算校验和的操作。