在 Linux 存储子系统中，request 队列（request queue）是块设备层的核心枢纽。它负责管理所有 I/O 请求，从文件系统、页缓存、swap 或 Direct I/O 生成的请求，到最终提交到设备的全过程都通过 request 队列。它不仅承担 I/O 合并、排序、限流、调度，还在多队列架构下发挥并行性能。理解 request 队列的设计原理和工作机制，对于优化存储性能、分析 I/O 瓶颈、调优内核和应用程序都至关重要。

    我们从架构视角、数据结构、生命周期、合并机制、调度策略及多队列扩展六个方面，深度解析 Linux request 队列，每章理论内容丰富，保证技术深度与可读性。

第一章：Linux Block Layer 架构与 request 队列的位置

1.1 块设备 I/O 的整体路径

    Linux 存储 I/O 是典型的分层架构设计，I/O 请求从用户态到硬件设备经历多层模块，包括系统调用层、虚拟文件系统（VFS）、文件系统、页缓存（Page Cache）以及块设备层。request 队列位于块层中，承担着连接上层文件系统和下层设备驱动的桥梁作用。

    request 队列不仅仅是 I/O 缓存，它还是 I/O 调度和性能优化中心。在传统单队列设计中，所有请求通过一个全局锁管理，这在低并发环境下没有问题，但在现代多核 CPU 和高性能 NVMe SSD 场景下，单锁成为瓶颈。通过 request 队列，Linux 可以实现 I/O 合并、排序、调度和深度控制，优化整体 I/O 流量。

    理解 request 队列在存储路径中的位置，能够帮助开发者准确把握 I/O 性能瓶颈。比如，随机 I/O 延迟高时，问题可能不是硬件，而是 request 队列合并策略或调度策略不当。

1.2 request 队列在内核中的结构位置

    每个块设备在 Linux 内核中都有一个 struct request_queue 结构体。这个结构体是 request 队列的核心表示，包含了：

• 请求列表管理

• I/O 调度器接口（elevator）

• 多队列映射（blk-mq）

• 队列深度和并发控制

• 队列锁保护

其结构可以简化表示为：

struct request_queue {    struct request *last_merge;    struct elevator_queue *elevator;    struct blk_mq_tag_set *tag_set;    struct blk_mq_ops *mq_ops;    struct list_head queue_head;    unsigned int nr_requests;    unsigned int queue_depth;    spinlock_t queue_lock;};

    从设计角度看，request 队列结合锁机制、调度接口和队列管理，实现了 统一的 I/O 控制中心，为上层文件系统提供统一、可优化的 I/O 提交入口。理解这个结构有助于调试 I/O 问题，比如延迟异常或队列过长。

1.3 request 队列的设计目标

request 队列设计目标主要包括以下几个方面：

1. I/O 合并与优化：减少磁盘寻道次数，提高顺序访问吞吐量。

2. I/O 排序：减少机械硬盘的随机寻道，提高效率。

3. 并发控制：限制设备同时处理的请求数量，避免过载。

4. 调度策略支持：提供多种 I/O 调度器接口，以适应不同应用场景需求，如数据库随机访问或日志顺序写入。

5. 多队列扩展支持：blk-mq 架构下可实现多 CPU 并行 I/O，提升现代 SSD 与 NVMe 设备的吞吐能力。

request 队列的设计理念不仅是数据结构，更是一套 内核 I/O 流量控制和性能优化方案。

第二章：request 数据结构与生命周期

2.1 request 结构体解析

    在 Linux 内核中，一个 I/O 请求由 struct request 表示，每个 request 可以包含多个 BIO（块 I/O 单元）。核心字段包括：

    request 不仅是 BIO 的容器，还承担 合并、排序、调度 等功能，是块层处理 I/O 的核心对象。了解其字段和用途，有助于深入分析 I/O 延迟、队列瓶颈和调度策略。

2.2 BIO 与 request 的关系

    BIO 是最基本的 I/O 单元，用于描述内存页、偏移和扇区号等信息。request 是 BIO 的集合，通过 request 可将多个小 I/O 合并为一个大请求，提高顺序访问性能。例如：

应用提交 3 个 BIO → 合并为 1 个 request → request queue → I/O 调度 → 设备

这种设计使得块层既能支持高并发小 I/O，也能优化顺序大块 I/O，是 Linux 存储架构的核心优势。

2.3 request 生命周期

request 生命周期包括：

1. 生成 BIO：文件系统或页缓存提交请求。

2. request 分配：blk-mq 或传统块层分配 request 对象。

3. 加入 request 队列：排队等待调度。

4. 调度与排序：I/O 调度器按策略重排请求顺序。

5. 派发到设备驱动：驱动提交 request 到硬件。

6. 设备执行 I/O：硬件完成操作。

7. 中断通知完成：驱动通过中断通知块层。

8. request 完成回收：释放资源并更新状态。

    理解 request 生命周期有助于定位性能瓶颈，例如高延迟可能是调度器排序或队列深度不足导致。

第三章：request 队列的创建与初始化

3.1 块设备注册流程

当块设备驱动加载时，会调用接口创建 request 队列：

• 传统队列：blk_alloc_queue()

• blk-mq 架构：blk_mq_init_queue()

流程包括：

1. 初始化队列锁与数据结构

2. 分配硬件 tag 资源（blk-mq）

3. 初始化 I/O 调度器

4. 将队列与块设备绑定

初始化完成后，设备可以接收上层 I/O 请求并执行调度。

3.2 request_queue 初始化细节

request_queue 初始化内容包括：

• 队列锁：保护队列访问，防止多 CPU 并发冲突。

• 调度器初始化：为不同类型 I/O 提供合并、排序、优先级控制。

• 硬件队列映射：每个 CPU 的软件队列可以映射到不同硬件队列，支持并行 I/O。

• 队列深度和统计：控制同时挂起 request 数量，便于性能调优。

正确初始化 request_queue 对 I/O 性能至关重要，尤其是在多核和 NVMe 环境下。

3.3 队列参数分析

常用参数包括：

• nr_requests：最大 request 数

• scheduler：调度器类型

• read_ahead_kb：顺序读预取

• max_sectors_kb：单 request 最大扇区数

这些参数直接影响队列性能。例如 SSD 推荐使用 none 调度器，减少 CPU 调度开销，提高 I/O 并发效率。

第四章：I/O 合并机制

4.1 request 合并原理

request 合并是块层优化的核心，减少 I/O 请求数和磁盘寻道。主要有：

• Front Merge：新请求在队列前端与已有 request 合并

• Back Merge：新请求在队列末端合并

例如：

Request: sector 100-120BIO:     sector 121-130 → Back MergeBIO:     sector 90-99   → Front Merge

通过合并，可以显著提升顺序访问吞吐量。

4.2 合并算法实现

核心函数为 blk_attempt_merge()，逻辑包括：

1. 检查扇区连续性

2. 检查 I/O 类型（读/写）一致

3. 检查队列限制（最大扇区数）

4. 执行合并并更新 request

合并策略在 HDD 上效果显著，而在 SSD 上收益有限，过度合并可能增加 CPU 开销。

4.3 合并对性能的影响

    合并减少 request 数量和磁头寻道，提高吞吐量。同时，request 合并与调度器策略协作，可优化 I/O 延迟波动。例如，数据库随机访问场景可能减少合并以降低单次延迟，而顺序写日志场景则最大化合并以提升吞吐。

第五章：request 调度与 I/O 调度器

5.1 电梯调度模型

I/O 调度器通过电梯算法优化磁头移动：

当前磁头位置：100请求：20、50、120、180执行顺序：120 → 180 → 50 → 20

电梯算法减少机械硬盘寻道，降低随机访问延迟。调度器策略直接影响 request 执行顺序和 I/O 性能。

5.2 常见调度器分析

• CFQ：公平队列，适合桌面场景，多任务公平分配带宽。

• Deadline：保证请求延迟上限，防止 I/O 饥饿，适合数据库或延迟敏感应用。

• BFQ：预算公平队列，提供 I/O 权重分配，优化多任务吞吐。

• None：适合 NVMe SSD，由硬件管理 I/O，减少内核开销。

选择适合的调度器是 I/O 性能优化关键。

5.3 调度器接口与机制

核心结构 struct elevator_type 提供回调：

• insert_requests()：插入 request

• dispatch_request()：调度 request

• completed_request()：完成回收

调度器与 request_queue 配合，通过排序、合并和限流实现不同 I/O 策略，影响系统吞吐和延迟表现。

第六章：blk-mq 多队列 request 机制

6.1 为什么需要 blk-mq

    传统 request 队列使用单锁 queue_lock 管理 I/O，CPU 多核下容易产生严重锁竞争。NVMe SSD 每秒可处理百万级 IOPS，如果全局锁争用严重，将极大限制并行性能。blk-mq 引入多队列架构，每个 CPU 本地操作自己的软件队列，减少锁竞争，同时充分利用设备硬件队列能力。

6.2 多队列架构原理

    每个 CPU 拥有独立软件队列（SW Queue），映射到硬件队列（HW Queue）。设计原则：

• 并行化：CPU 可独立处理 request

• 负载均衡：多硬件队列分散 I/O 压力

• 缓存局部性优化：软件队列在 CPU 本地，提高访问速度

• 队列深度精细控制：避免延迟波动

CPU0 → SW Queue0 → HW Queue0 → NVMeCPU1 → SW Queue1 → HW Queue1 → NVMeCPU2 → SW Queue2 → HW Queue2 → NVMe

6.3 tag 机制与高并发 I/O

blk-mq 使用 tag 标识 request 在硬件队列中的槽位。tag 流程：

1. 分配 tag

2. 提交 request

3. 硬件执行

4. tag 回收

优势：

• 锁竞争小

• 支持高并发

• O(1) 查找 request

• 灵活扩展 CPU/队列数量

结合调度器策略（如 mq-deadline 或 bfq），blk-mq 能实现高吞吐、低延迟和公平性，是现代 Linux 存储性能优化的核心。

    request 队列是 Linux 块设备层核心枢纽，通过合并、排序、调度和多队列扩展，Linux 能在高并发环境下充分发挥存储性能。深入理解 request 队列机制，对 I/O 性能优化、瓶颈分析和高性能存储系统开发具有重要意义。