为什么没有实现复合系统调用之类的东西？

这已经存在。在 Linux 上，它由io_uring实现，自内核版本 5.1（2019 年 5 月）起可用：操作被放置在一个队列（或者更确切地说，环）上并且在没有系统调用的情况下进行处理，它们的结果将进入另一个队列。

一般概念已经完成并且确实存在。正如 Stephen Kitt 的回答所指出的，最接近的示例是 Linux 上的 io_uring，但它远非此类接口的唯一示例。Windows、Solaris、AmigaOS 和少数其他操作系统都具有类似的面向 IO 的完成队列机制，其工作方式与 io_uring 类似（Linux 实际上有点晚了）。

此外，类 UNIX 系统上实际上有很多系统调用，虽然它们不像您建议的那样工作，但通过将一些通常在用户空间中完成的任务推入内核来避免大量潜在的上下文切换。系统sendfile()调用可能是此类系统调用的最佳示例，它执行一项非常常见的任务（将大量数据从一个文件描述符复制到另一个文件描述符）并将其完全推送到内核模式，从而完全避免循环和大量上下文切换（和额外的缓冲区）在用户空间中执行此操作所需的。

不过，这里要理解的一个关键问题是，为了使它有意义，像这样批量设置与相关操作集相关的所有内容的成本必须低于仅以“正常”方式进行的成本。只有在处理大量IO 时使用 io_uring 才有意义，例如在为 VM 模拟块存储设备时（QEMU 支持为此使用它，即使在快速主机硬件上的性能差异也是疯狂的），或者读取数千每秒处理一次文件（我工作的公司最近开始在内部讨论可能对此类工作负载使用 io_uring）。相似地，sendfile()仅当您需要多次读/写迭代来通过用户空间复制数据时才有意义（尽管这通常是无法负担用户空间中的缓冲区空间的功能，而不是运行读/写迭代更快） .

此外，系统调用实际上必须在批处理上下文中有意义。如果处理保留调用的顺序，IO 通常在这里有意义，但很多事情都没有。例如，尝试使用这种类型的接口是愚蠢的（可能exec()是 fork 和 exec 的组合，但不是普通的 exec）。同样，某些类型的系统调用只有在单独处理时才有用。操纵进程的信号掩码就是一个很好的例子，除了初始设置之外，您几乎总是这样做是为了保护代码中的关键部分，并且您通常需要为此目的进行及时、可预测的处理。

这些功能已经存在了很长时间。

1997 年的 Solaris 2.6添加了一个内核异步 IO 系统调用，它正是这样做的 - kaio()。

访问它的一种方法是通过`lio_listio() 函数：

lio_listio

• 列出定向 I/O

概要

cc [ flag... ] file... -lrt [ library... ]
#include <aio.h>

int lio_listio(int mode, struct aiocb *restrict const list[], int nent,
     struct sigevent *restrict sig);

描述

该lio_listio()函数允许调用进程、LWP 或线程在单个函数调用中启动 I/O 请求列表。

可以在https://github.com/illumos/illumos-gate/blob/470204d3561e07978b63600336e8d47cc75387fa/usr/src/lib/libc/port/aio中找到Illumoslibc源代码，该源代码是开源的并且源自原始的 Solaris 实现/posix_aio.c#L121lio_listio()

此类功能不常见的原因之一是，除非整个软件和硬件系统旨在利用它，否则它们实际上不会提高性能。

必须配置存储以提供正确对齐的块，必须构建文件系统以便它们与存储系统提供的块正确对齐，并且需要编写整个软件堆栈以免搞砸 IO - 这一切都有做正确对齐的 IO。

对于旋转磁盘，对同一磁盘的一批 IO 操作很容易相互干扰，并且实际上会随着磁头花费更多时间寻找而减慢一切。

根据我的经验，只需要其中一层做错事情，批处理系统调用的性能优势就会消失在开销中。因为与最糟糕的系统调用开销相比，IO 是缓慢的。

创建和维护组合的硬件/软件系统以利用批处理 IO 系统调用提供的性能改进的成本是巨大的。

我见过的最好的数字是将许多 IO 调用批处理到一个系统调用中可以提高大约 25-30% 的性能。

如果您全天候连续处理数百 GB 的数据，那很重要。

构建和维护这样的整个系统只是为了将观看猫视频的延迟从 8 毫秒降低到 6 毫秒？没那么多。