Documentation/translations/zh_CN/block/blk-mq.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/zh_CN/block/blk-mq.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/zh_CN/block/blk-mq.rst
Extension
.rst
Size
6553 bytes
Lines
130
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0
.. include:: ../disclaimer-zh_CN.rst

:Original: Documentation/block/blk-mq.rst

:翻译:

 柯子杰 kezijie <kezijie@leap-io-kernel.com>

:校译:



================================================
多队列块设备 I/O 排队机制 (blk-mq)
================================================

多队列块设备 I/O 排队机制提供了一组 API，使高速存储设备能够同时在多个队列中
处理并发的 I/O 请求并将其提交到块设备，从而实现极高的每秒输入/输出操作次数
(IOPS)，充分发挥现代存储设备的并行能力。

介绍
====

背景
----

磁盘从 Linux 内核开发初期就已成为事实上的标准。块 I/O 子系统的目标是尽可能
为此类设备提供最佳性能，因为它们在进行随机访问时代价极高，性能瓶颈主要在机械
运动部件上，其速度远低于存储栈中其他任何层。其中一个软件优化例子是根据硬盘磁
头当前的位置重新排序读/写请求。

然而，随着固态硬盘和非易失性存储的发展，它们没有机械部件，也不存在随机访问代
码，并能够进行高速并行访问，存储栈的瓶颈从存储设备转移到了操作系统。为了充分
利用这些设备设计中的并行性，引入了多队列机制。

原来的设计只有一个队列来存储块设备 I/O 请求，并且只使用一个锁。由于缓存中的
脏数据和多处理器共享单锁的瓶颈，这种设计在 SMP 系统中扩展性不佳。当不同进程
（或同一进程在不同 CPU 上）同时执行块设备 I/O 时，该单队列模型还会出现严重
的拥塞问题。为了解决这些问题，blk-mq API 引入了多个队列，每个队列在本地 CPU
上拥有独立的入口点，从而消除了对全局锁的需求。关于其具体工作机制的更深入说明，
请参见下一节（ `工作原理`_ ）。

工作原理
--------

当用户空间执行对块设备的 I/O（例如读写文件）时，blk-mq 便会介入：它将存储和
管理发送到块设备的 I/O 请求，充当用户空间（文件系统，如果存在的话）与块设备驱
动之间的中间层。

blk-mq 由两组队列组成：软件暂存队列和硬件派发队列。当请求到达块层时，它会尝
试最短路径：直接发送到硬件队列。然而，有两种情况下可能不会这样做：如果该层有
IO 调度器或者是希望合并请求。在这两种情况下，请求将被发送到软件队列。

随后，在软件队列中的请求被处理后，请求会被放置到硬件队列。硬件队列是第二阶段
的队列，硬件可以直接访问并处理这些请求。然而，如果硬件没有足够的资源来接受更
多请求，blk-mq 会将请求放置在临时队列中，待硬件资源充足时再发送。

软件暂存队列
~~~~~~~~~~~~

在这些请求未直接发送到驱动时，块设备 I/O 子系统会将请求添加到软件暂存队列中
（由 struct blk_mq_ctx 表示）。一个请求可能包含一个或多个 BIO。它们通过 struct bio
数据结构到达块层。块层随后会基于这些 BIO 构建新的结构体 struct request，用于
与设备驱动通信。每个队列都有自己的锁，队列数量由每个 CPU 和每个 node 为基础
来决定。

暂存队列可用于合并相邻扇区的请求。例如，对扇区3-6、6-7、7-9的请求可以合并
为对扇区3-9的一个请求。即便 SSD 或 NVM 的随机访问和顺序访问响应时间相同，
合并顺序访问的请求仍可减少单独请求的数量。这种合并请求的技术称为 plugging。

Annotation

Implementation Notes