在 Linux 中，零碎调用（syscalls）是所有的外围。它们是应用程序与内核交互的次要接口。因而，至关重要的是它们要快。尤其在后 Spectre / Meltdown 后世界中，这一点尤为重要。
如果感觉看完文章有所播种的话，能够关注我一下哦
知乎：秃顶之路
b 站：linux 亦有归途
每天都会更新咱们的公开课录播以及编程干货和大厂面经
或者间接点击链接 c /c++ linux 服务器开发高级架构师
来课堂上跟咱们讲师面对面交换
须要大厂面经跟学习纲要的小伙伴能够加群 973961276 获取
大部分零碎调用都解决 I / O，因为大多数应用程序都是这样做的。对于网络 I / O，咱们领有 epoll一系列 syscall，它们为咱们提供了相当快的性能。然而在文件系统 I / O 部门中，有点不足。咱们曾经有 async_io一段时间了，然而除了大量的利基应用程序之外，它并不是十分无益。次要起因是它仅在应用 关上文件时才起作用 O_DIRECT标记。这将使内核绕过所有操作系统缓存，并尝试间接在设施之间进行读写。当咱们试图使事件停顿很快时，这不是执行 I / O 的好办法。在缓冲模式下，它将同步运行。
All that is changing slowly because now we have a brand new interface to perform I/O with the kernel: io_uring。
四周有很多嗡嗡声。没错，因为它为咱们提供了一个与内核进行交互的全新模型。让咱们深入研究它，并尝试理解它是什么以及它如何解决问题。而后，咱们将应用 Go 来构建一个小型演示应用程序来应用它。
背景
让咱们退后一步，想一想通常的零碎调用是如何工作的。咱们进行零碎调用，咱们在用户层中的应用程序调用内核，并在内核空间中复制数据。实现内核执行后，它将后果复制回用户空间缓冲区。而后返回。所有这些都在 syscall 依然被阻止的状况下产生。
马上，咱们能够看到很多瓶颈。有很多复制，并且有阻塞。Go 通过在应用程序和内核之间引入另一层来解决此问题：运行时。它应用一个虚构实体（通常称为 P），其中蕴含要运行的 goroutine 队列，而后将其映射到 OS 线程。
这种间接级别使它能够进行一些乏味的优化。每当咱们进行阻塞的 syscall 时，运行时就晓得了，它会将线程与 的 拆散 P 执行 goroutine，并取得一个新线程来执行其余 goroutine。这称为越区切换。而当零碎调用返回时，运行时尝试将其重新安装到 P。如果无奈取得收费的 P，它将把 goroutine 推入队列以待稍后执行，并将线程存储在池中。当您的代码进入零碎调用时，这就是 Go 出现“非阻塞”状态的形式。
很好，然而依然不能解决次要问题，即依然产生复制并且理论的 syscall 依然阻塞。
让咱们考虑一下手头的第一个问题：复制。咱们如何避免从用户空间复制到内核空间？好吧，显然咱们须要某种共享内存。好的，能够应用 来实现，该 mmap零碎调用 零碎调用能够映射用户与内核之间共享的内存块。
那须要复制。然而同步呢？即便咱们不复制，咱们也须要某种形式来同步咱们和内核之间的数据拜访。否则，咱们将遇到雷同的问题，因为应用程序将须要再次进行 syscall 能力执行锁定。
如果咱们将问题视为用户和内核是两个互相独立的组件，那么这实质上就是生产者-消费者问题。用户创立零碎调用申请，内核承受它们。实现后，它会向用户发出信号，表明已准备就绪，并且用户会承受它们。
侥幸的是，这个问题有一个古老的解决方案：环形缓冲区。环形缓冲区容许生产者和使用者之间实现高效同步，而基本没有锁定。正如您可能曾经晓得的那样，咱们须要两个环形缓冲区：一个提交队列（SQ），其中用户充当生产者并推送 syscall 申请，内核应用它们；还有一个实现队列（CQ），其中内核是生产者推动实现后果，而用户应用它们。
应用这种模型，咱们齐全打消了所有内存正本和锁定。从用户到内核的所有通信都能够十分高效地进行。这本质上是 的核心思想 io_uring施行。让咱们简要介绍一下它的外部，看看它是如何实现的。
io_uring 简介
要将申请推送到 SQ，咱们须要创立一个提交队列条目（SQE）。假如咱们要读取文件。略过许多细节，SQE 基本上将蕴含：
- 操作码 ：形容要进行的零碎调用的操作码。因为咱们对读取文件感兴趣，因而咱们将应用 的
readv映射到操作码 零碎调用IORING_OP_READV。 - 标记：这些是能够随任何申请传递的修饰符。咱们稍后会解决。
- Fd：咱们要读取的文件的文件描述符。
- 地址 ：对于咱们的
readv调用，它将创立一个缓冲区（或向量）数组以将数据读入其中。因而，地址字段蕴含该数组的地址。 - Length：向量数组的长度。
- 用户数据：一个标识符，用于将咱们的申请从实现队列中移出。请记住，不能保障实现后果的程序与 SQE 雷同。那会毁坏应用异步 API 的全副目标。因而，咱们须要一些货色来辨认咱们提出的申请。这达到了目标。通常，这是指向一些保留有申请元数据的构造的指针。
在实现方面，咱们从 CQ 取得实现队列事件（CQE）。这是一个非常简单的构造，其中蕴含：
- 后果：的返回值
readvsyscall。如果胜利，它将读取字节数。否则，它将具备错误代码。 - 用户数据：咱们在 SQE 中传递的标识符。
这里只须要留神一个重要的细节：SQ 和 CQ 在用户和内核之间共享。然而，只管 CQ 实际上蕴含 CQE，但对于 SQ 而言却有所不同。它实质上是一个间接层，其中 SQ 数组中的索引值实际上蕴含保留 SQE 项的理论数组的索引。这对于某些在内部结构中具备提交申请的应用程序很有用，因而容许它们在一个操作中提交多个申请，从实质上简化了 的采纳 io_uringAPI。
这意味着咱们实际上在内存中映射了三件事：提交队列，实现队列和提交队列数组。下图应使状况更分明：
当初，让咱们从新拜访 的 flags之前跳过 字段。正如咱们所探讨的，CQE 条目可能齐全不同于队列中提交的条目。这带来了一个乏味的问题。如果咱们要一个接一个地执行一系列 I / O 操作怎么办？例如，文件正本。咱们想从文件描述符中读取并写入另一个文件。在以后状态下，咱们甚至无奈开始提交写入操作，直到看到 CQ 中呈现读取事件为止。那就是 的中央 flags进来。
咱们能够 设置 IOSQE_IO_LINK在 flags现场 以实现这一指标。如果设置了此选项，则下一个 SQE 将主动链接到该 SQE，直到以后 SQE 实现后它才开始。这使咱们可能按所需形式对 I / O 事件执行排序。文件复制只是一个示例。从实践上讲，咱们能够 链接 任何 彼此 零碎调用，直到在未设置该字段的状况下推送 SQE，此时该链被视为已损坏。
零碎调用
通过对 简要概述 io_uring操作形式的，让咱们钻研实现它的理论零碎调用。只有两个。
int io_uring_setup(unsigned entries, struct io_uring_params *params);
的 entries示意 SQEs 的数量为该环。params是一个构造，其中蕴含无关应用程序要应用的 CQ 和 SQ 的各种详细信息。它向该 返回文件描述符 io_uring实例。
int io_uring_enter(unsigned int fd, unsigned int to_submit, unsigned int min_complete, unsigned int flags, sigset_t sig);
该调用用于向内核提交申请。让咱们疾速浏览以下重要内容：
fd是上一次调用返回的环的文件描述符。to_submit通知内核要从环中耗费多少条目。请记住，这些环位于共享内存中。因而，在要求内核解决它们之前，咱们能够随便推送任意数量的条目。min_complete批示在返回之前，呼叫应期待多少条目能力实现。
精明的读者会留神到，中具备 to_submit和 min_complete在雷同的调用 意味着咱们能够应用它来仅提交，或仅实现，甚至两者！这将关上 API，以依据应用程序工作负载以各种乏味的形式应用。
轮询模式
对于提早敏感的应用程序或具备极高 IOPS 的应用程序，每次有可用数据读取时让设施驱动程序中断内核是不够高效的。如果咱们要读取大量数据，那么高中断率实际上会减慢用于处理事件的内核吞吐量。在这些状况下，咱们实际上会退回轮询设施驱动程序。要将轮询与一起应用 io_uring，咱们能够 设置 IORING_SETUP_IOPOLL在 标记 io_uring_setup呼叫中，并将轮询事件与 的 保持一致 IORING_ENTER_GETEVENTS设置 io_uring_enter呼叫中。
但这依然须要咱们（用户）拨打电话。为了进步性能，，io_uring它还具备称为“内核侧轮询”的性能 通过该性能，如果将 设置为 IORING_SETUP_SQPOLL标记 io_uring_params，内核将主动轮询 SQ 以查看是否有新条目并应用它们。这基本上意味着咱们能够持续做所有的 I / 咱们想Ø不执行甚至一个 繁多的 。 零碎 。 打电话。这扭转了所有。
然而，所有这些灵活性和原始功率都是有代价的。间接应用此 API 并非易事且容易出错。因为咱们的数据结构是在用户和内核之间共享的，因而咱们须要设置内存屏障（神奇的编译器命令以强制执行内存操作的程序）和其余技巧，以正确实现工作。
侥幸的是，的创建者 Jens Axboe io_uring创立了一个包装器库，liburing以帮忙简化所有操作。应用 liburing，咱们大抵必须执行以下步骤：
io_uring_queue_(init|exit)设置并拆下戒指。io_uring_get_sqe取得 SQE。io_uring_prep_(readv|writev|other)标记要应用的零碎调用。io_uring_sqe_set_data标记用户数据字段。io_uring_(wait|peek)_cqe期待 CQE 或不期待而窥视它。io_uring_cqe_get_data取回用户数据字段。io_uring_cqe_seen将 CQE 标记为实现。
在 Go 中包装 io_uring
有很多实践须要消化。为了简洁起见，我特意跳过了更多内容。当初，让咱们回到用 Go 语言编写一些代码，并尝试一下。
为了简略和平安起见，咱们将应用该 liburing库，这意味着咱们将须要应用 CGo。很好，因为这只是一个玩具，正确的办法是 取得 本机反对 在 Go 运行时中。后果，可怜的是，咱们将不得不应用回调。在本机 Go 中，正在运行的 goroutine 将在运行时进入睡眠状态，而后在实现队列中的数据可用时被唤醒。
让咱们给程序包命名 frodo（就像这样，我淘汰了计算机科学中两个最艰难的问题之一）。咱们将只有一个非常简单的 API 来读写文件。还有另外两个性能可在实现后设置和清理环。
咱们的次要力量将是单个 goroutine，它将承受提交申请并将其推送到 SQ。而后从 C 中应用 CQE 条目对 Go 进行回调。咱们将应用 fd一旦取得数据，文件的来晓得要执行哪个回调。然而，咱们还须要确定何时将队列理论提交给内核。咱们维持一个队列阈值，如果超过了未决申请的阈值，咱们将提交。而且，咱们向用户提供了另一个性能，容许他们本人进行提交，以使他们能够更好地控制应用程序的行为。
再次留神，这是一种低效的解决形式。因为 CQ 和 SQ 齐全离开，因而它们基本不须要任何锁定，因而提交和实现能够从不同的线程中自在进行。现实状况下，咱们只需将一个条目推送到 SQ 并让一个独自的 goroutine 监听期待实现的工夫，每当看到一个条目时，咱们都会进行回调并回到期待状态。还记得咱们能够用来 io_uring_enter实现工作吗？这是一个这样的例子！这依然使每个 CQE 条目只有一个零碎调用，咱们甚至能够通过指定要期待的 CQE 条目数来进一步优化它。
回到咱们的简化模型，这是它的样子的伪代码：
// ReadFile reads a file from the given path and returns the result as a byte slice
// in the passed callback function.
func ReadFile(path string, cb func(buf []byte)) error {f, err := os.Open(path)
// handle error
fi, err := f.Stat()
// handle error
submitChan <- &request{
code: opCodeRead, // a constant to identify which syscall we are going to make
f: f, // the file descriptor
size: fi.Size(), // size of the file
readCb: cb, // the callback to call when the read is done
}
return nil
}// WriteFile writes data to a file at the given path. After the file is written,
// it then calls the callback with the number of bytes written.
func WriteFile(path string, data []byte, perm os.FileMode, cb func(written int)) error {f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, perm)
// handle error submitChan <- &request{
code: opCodeWrite, // same as above. This is for the writev syscall
buf: data, // the byte slice of data to be written
f: f, // the file descriptor
writeCb: cb, // the callback to call when the write is done
}
return nil
}
submitChan将申请发送给咱们的次要工作人员，由他们负责提交。这是伪代码：
queueSize := 0
for {
select {
case sqe := <-submitChan:
switch sqe.code {
case opCodeRead:
// We store the fd in our cbMap to be called later from the callback from C.
cbMap[sqe.f.Fd()] = cbInfo{
readCb: sqe.readCb,
close: sqe.f.Close,
}
C.push_read_request(C.int(sqe.f.Fd()), C.long(sqe.size))
case opCodeWrite:
cbMap[sqe.f.Fd()] = cbInfo{
writeCb: sqe.writeCb,
close: sqe.f.Close,
}
C.push_write_request(C.int(sqe.f.Fd()), ptr, C.long(len(sqe.buf)))
}
queueSize++
if queueSize > queueThreshold { // if queue_size > threshold, then pop all.
submitAndPop(queueSize)
queueSize = 0
}
case <-pollChan:
if queueSize > 0 {submitAndPop(queueSize)
queueSize = 0
}
case <-quitChan:
// possibly drain channel.
// pop_request till everything is done.
return
}
}cbMap将文件描述符映射到要调用的理论回调函数。当 CGo 代码调用 Go 代码来示意事件实现 代码 submitAndPop调用时，io_uring_submit_and_wait应用此 queueSize，而后从 CQ 弹出条目。
让咱们来看看成什么 C.push_read_request和 C.push_write_request做。他们实际上所做的只是向 SQ 推送读 / 写申请。
他们看起来像这样：
int push_read_request(int file_fd, off_t file_sz) {
// Create a file_info struct
struct file_info *fi;
// Populate the struct with the vectors and some metadata
// like the file size, fd and the opcode IORING_OP_READV.
// Get an SQE.
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
// Mark the operation to be readv.
io_uring_prep_readv(sqe, file_fd, fi->iovecs, total_blocks, 0);
// Set the user data section.
io_uring_sqe_set_data(sqe, fi);
return 0;
}
int push_write_request(int file_fd, void *data, off_t file_sz) {
// Create a file_info struct
struct file_info *fi;
// Populate the struct with the vectors and some metadata
// like the file size, fd and the opcode IORING_OP_WRITEV.
// Get an SQE.
struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
// Mark the operation to be writev.
io_uring_prep_writev(sqe, file_fd, fi->iovecs, 1, 0);
// Set the user data section.
io_uring_sqe_set_data(sqe, fi);
return 0;
}
当 submitAndPop尝试从 CQ 弹出条目时，将执行以下命令：
int pop_request() {
struct io_uring_cqe *cqe;
// Get an element from CQ without waiting.
int ret = io_uring_peek_cqe(&ring, &cqe);
// some error handling
// Get the user data set in the set_data call.
struct file_info *fi = io_uring_cqe_get_data(cqe);
if (fi->opcode == IORING_OP_READV) {
// Calculate the number of blocks read.
// Call read_callback to Go.
read_callback(fi->iovecs, total_blocks, fi->file_fd);
} else if (fi->opcode == IORING_OP_WRITEV) {
// Call write_callback to Go.
write_callback(cqe->res, fi->file_fd);
}
// Mark the queue item as seen.
io_uring_cqe_seen(&ring, cqe);
return 0;
}在 read_callback与 write_callback从刚刚失去的条目 cbMap与传递 fd和调用所需的回调函数最后收回 ReadFile/ WriteFile电话。
//export read_callback
func read_callback(iovecs *C.struct_iovec, length C.int, fd C.int) {
var buf bytes.Buffer
// Populate the buffer with the data passed.
cbMut.Lock()
cbMap[uintptr(fd)].close()
cbMap[uintptr(fd)].readCb(buf.Bytes())
cbMut.Unlock()}
//export write_callback
func write_callback(written C.int, fd C.int) {cbMut.Lock()
cbMap[uintptr(fd)].close()
cbMap[uintptr(fd)].writeCb(int(written))
cbMut.Unlock()}基本上就是这样！如何应用该库的示例如下：
err := frodo.ReadFile("shire.html", func(buf []byte) {// handle buf})
if err != nil {// handle err}随时查看 源代码，以深刻理解实现的细节。
性能
没有一些性能数字，没有任何博客文章是残缺的。然而，对 I / O 引擎进行适当的基准测试比拟可能会须要另外一篇博客文章。为了残缺起见，我将简短而迷信的测试后果公布到笔记本电脑上。不要过多地浏览它，因为任何基准测试都高度依赖于工作负载，队列参数，硬件，一天中的工夫以及衬衫的色彩。
咱们将应用 fio 由 Jens 本人编写的丑陋工具 来对具备不同工作负载的多个 I / O 引擎进行基准测试，同时反对 io_uring和 libaio。旋钮太多，无奈更改。然而，咱们将应用比率为 75/25 的随机读 / 写工作量，应用 1GiB 文件以及 16KiB，32KiB 和 1MiB 的不同块大小来执行一个非常简单的试验。而后，咱们以 8、16 和 32 的队列大小反复整个试验。
请留神，这是 io_uring不轮询的基本模式，在这种状况下，后果可能更高。
论断
这是一篇相当长的文章，十分感谢您浏览本文！
io_uring仍处于起步阶段，但很快就吸引了很多人。许多知名人士（例如 libuv 和 RocksDB）曾经反对它。甚至有一个补丁能够 nginx减少 io_uring反对。
对 io 复用技术感兴趣的小伙伴还能够看看这个视频
高性能服务器《IO 复用技术》详解（上）