c - Linux 有零拷贝吗？拼接或发送文件？

Question

当引入 splice 时，内核列表中讨论了 sendfile 是基于 splice 重新实现的。拼接 SLICE_F_MOVE 的文档指出:

Attempt to move pages instead of copying. This is only a hint to the kernel: pages may still be copied if the kernel cannot move the pages from the pipe, or if the pipe buffers don't refer to full pages. The initial implementation of this flag was buggy: therefore starting in Linux 2.6.21 it is a no-op (but is still permitted in a splice() call); in the future, a correct implementation may be restored.

那么这是否意味着 Linux 没有用于写入套接字的零拷贝方法？或者这是在某个时候修复的，多年来没有人更新文档？ sendfile 或 splice 在任何最新的 3.x 内核版本中是否有零拷贝实现？

由于谷歌没有回答这个问题，我正在为下一个想知道使用 vmsplice 和 splice 或 sendfile 比普通的旧写是否有任何好处的可怜的笨蛋创建一个 stackoverflow 问题。

Answer 1

sendfile 从那以后一直是零拷贝(假设硬件允许，但通常是这种情况)。零拷贝是这个系统调用的全部意义所在。 sendfile 现在作为 splice 的包装器实现。

这表明 splice 也是零拷贝，事实确实如此。至少在理论上，至少在某些情况下。问题是弄清楚如何正确使用它，以便它可靠地工作，因此它是零拷贝的。文档……至少可以说是稀疏的。

特别是，splice 仅在页面作为“礼物”提供时才有效，即您不再拥有它们(形式上，但实际上您仍然拥有)。如果您只是将文件描述符拼接到套接字上，这不是问题，但如果您想从应用程序的地址空间或从一个管道拼接到另一个管道，这就是一个大问题。目前尚不清楚之后(以及何时)如何处理这些页面。文档声明您之后不得触摸这些页面或对它们做任何事情，永远不会，永远不会。因此，如果您按照文档的字母进行操作，则必须泄漏内存。
这显然是不正确的(不可能)，但是没有好的方法知道(至少对您而言!)何时可以安全地重用或释放该内存。执行 sendfile 的内核会知道，因为一旦它收到 TCP ACK，它就知道不再需要该数据。问题是，您永远看不到 ACK。当 splice 返回时，您所知道的就是数据已被接受发送(但您不知道它是否已经发送或接收，也不知道这将在何时发生).
这意味着您需要在应用程序层以某种方式解决这个问题，要么通过手动 ACK(通过可靠的 UDP 免费提供)，要么假设如果另一方发送对您的请求的答复，他们显然一定是收到了请求。

您必须管理的另一件事是有限的管道空间。默认是很小的，但是即使你加大尺寸，你也不能天真地拼接一个任意大小的文件。另一方面，sendfile 会让您这样做，这很酷。

总而言之，sendfile 很好，因为它可以正常工作，而且很好，您无需关心上述任何细节。它不是 Elixir ，但确实是一个很好的补充。
就个人而言，我会远离 splice 及其家族，直到对整个事情进行彻底检查，直到 100% 清楚你必须做什么(以及什么时候)以及你不必做什么做。

无论如何，对于大多数应用程序而言，相对于普通旧式 write 的真正有效 yield 是微不足道的。我记得几年前 Torvalds 先生的一些不太礼貌的评论(当时 BSD 有一种 write 的形式，它可以通过重新映射页面来实现零拷贝，而 Linux 没有)其中指出制作副本通常没有任何问题，但在页面上玩把戏是[这里不再重复]。