4. 请求队列（Request Queue）深度解析

请求队列是块设备层IO调度的核心枢纽，它连接了上层的文件系统/通用块层与下层的设备驱动。本章将深入剖析 request_queue 结构体的内部布局、调度器挂载机制、关键参数配置以及并发控制策略。

4.1 request_queue 结构体全景

request_queue 是块设备层最复杂的数据结构之一，定义在 <linux/blkdev.h> 中。它包含了调度器实例、IO统计信息、限速器、硬件限制、并发控制锁等核心组件。以下SVG展示了其主要成员的分组关系：

request_queue 核心成员分组 调度器挂载点 • struct elevator_queue *elevator • struct blk_mq_ctx *mq_ctx • struct blk_mq_hw_ctx **hctxs • struct blk_mq_tag_set *tag_set • struct list_head queue_head • struct request_list rq • spinlock_t queue_lock 参数与硬件限制 • unsigned long nr_requests • unsigned int queue_depth • struct queue_limits limits • unsigned int max_sectors • unsigned int max_segments • unsigned int max_hw_sectors • unsigned int max_segment_size 统计与状态 • struct blk_queue_stats *stats • struct blk_rq_stat *rq_stats • unsigned long flags • struct kobject kobj • struct device *dev • struct work_struct timeout_work • struct timer_list timeout 说明 request_queue 是块设备层的核心数据结构，包含调度器、参数限制、统计状态三大模块 请求队列生命周期 blk_alloc_queue blk_init_queue blk_queue_make_request blk_cleanup_queue 分配 → 初始化 → 设置请求处理函数 → 清理

4.2 队列调度器挂载点

调度器通过 elevator_queue 结构挂载到 request_queue 上。内核支持多种调度器类型，通过 elevator_type 注册机制实现动态切换。

调度器名称内核模块挂载函数适用场景
none (noop)elevator.celevator_init()NVMe、virtio-blk 等高性能设备
mq-deadlinemq-deadline.cdeadline_init_queue()传统 HDD、混合负载
bfqbfq-iosched.cbfq_init_queue()桌面交互、多媒体场景
kyberkyber-iosched.ckyber_init_queue()低延迟敏感、SSD

调度器挂载关键流程：

  1. 设备驱动调用 blk_mq_init_queue() 或 blk_init_queue() 创建 request_queue
  2. 内核根据 /sys/block/<dev>/queue/scheduler 中的配置选择调度器
  3. 调用 elevator_init() 分配 elevator_queue 并初始化调度器私有数据
  4. 调度器注册 .insert_requests、.dispatch_request 等回调函数
  5. IO请求通过 blk_mq_sched_insert_requests() 进入调度器

4.3 队列参数与 sysfs 接口

request_queue 通过 sysfs 暴露大量可调参数，用户空间可以通过 /sys/block/<dev>/queue/ 目录下的文件进行动态调整。

sysfs 文件对应参数类型说明
nr_requestsqueue->nr_requestsunsigned long队列中最大请求数（含调度器内）
queue_depthqueue->queue_depthunsigned int硬件队列深度（NVMe等设备）
max_sectors_kbqueue->limits.max_sectorsunsigned int单次IO最大扇区数（KB）
max_segmentsqueue->limits.max_segmentsunsigned short单次IO最大分散段数
schedulerqueue->elevatorstring当前调度器名称，可动态切换
io_pollqueue->limits.io_pollbool是否启用IO轮询模式
write_cachequeue->limits.write_cachestring写缓存策略（write back/through）
rotationalqueue->limits.rotationalbool是否为旋转设备（HDD）

调优建议：对于NVMe SSD，建议设置 nr_requests 为 256-512，queue_depth 匹配硬件能力（通常 64-1024），调度器选择 none 或 kyber。对于HDD，建议 nr_requests 为 128-256，调度器使用 mq-deadline。

4.4 队列深度与并发控制

队列深度（Queue Depth）是块设备层并发控制的核心指标，它决定了系统可以同时向设备提交多少个未完成的IO请求。过低的队列深度会导致设备利用率不足，过高则可能引发延迟抖动和资源竞争。

队列深度与并发控制机制 IO 提交路径 submit_bio → blk_mq_submit_bio → blk_mq_get_request 并发控制组件 nr_requests 限制 全局请求数上限 queue_depth 限制 硬件队列深度 tag 分配器 blk_mq_tag_set 调度器内并发 elevator 队列 设备驱动层 blk_mq_ops->queue_rq → 硬件队列 → 设备完成中断

4.4.1 并发控制核心参数

参数默认值作用域控制机制
nr_requests256 (可调)全局队列限制队列中所有请求总数，超过则阻塞提交
queue_depth64-1024 (设备相关)硬件队列限制未完成IO数量，由tag分配器管理
tag_set->nr_tagsnr_requests + 预留tag集合bitmap管理，每个tag对应一个请求槽位
hctx->dispatch_busy0硬件上下文调度器背压标记，触发延迟分发

4.4.2 背压（Backpressure）机制

当队列深度达到上限时，内核通过以下机制实现背压：

  1. 请求分配阻塞：blk_mq_get_request() 在tag耗尽时调用 __blk_mq_alloc_request() 进入等待队列
  2. 调度器节流：调度器的 .limit_depth 回调根据当前负载动态调整可用深度
  3. 硬件背压：设备驱动通过 blk_mq_stop_hw_queue() 暂停硬件队列提交
  4. IO优先级降级：低优先级请求在高负载时被延迟或合并

常见问题：队列深度设置过大（如 >2048）可能导致内存占用过高和延迟抖动；设置过小（如 <32）会导致设备利用率不足，IOPS下降。建议通过 fio 等工具进行压力测试，找到最佳平衡点。

4.5 队列参数动态调整示例

以下示例展示了如何通过 sysfs 和内核API调整队列参数：

# 查看当前队列参数
cat /sys/block/nvme0n1/queue/nr_requests
cat /sys/block/nvme0n1/queue/queue_depth
cat /sys/block/nvme0n1/queue/max_sectors_kb

# 动态调整参数（需要root权限）
echo 512 > /sys/block/nvme0n1/queue/nr_requests
echo 128 > /sys/block/nvme0n1/queue/queue_depth
echo 1024 > /sys/block/nvme0n1/queue/max_sectors_kb

# 切换调度器
echo "kyber" > /sys/block/nvme0n1/queue/scheduler
// 内核模块中调整队列参数示例
#include <linux/blkdev.h>

static void adjust_queue_params(struct request_queue *q)
{
    // 调整最大请求数
    blk_queue_max_requests(q, 512);

    // 调整最大扇区数（单位：扇区，512字节）
    blk_queue_max_hw_sectors(q, 2048);  // 1MB

    // 调整最大分散段数
    blk_queue_max_segments(q, 256);

    // 设置队列深度（仅对blk-mq有效）
    if (q->mq_ops) {
        struct blk_mq_tag_set *set = q->tag_set;
        set->queue_depth = 128;
    }
}

4.6 队列深度与性能关系

队列深度对IO性能的影响因设备类型而异，以下表格总结了典型场景下的最佳实践：

设备类型推荐队列深度推荐nr_requests调度器性能特征
NVMe SSD (高端)256-1024512-1024none / kyber高IOPS，低延迟，深度敏感
SATA SSD32-128128-256mq-deadline中等IOPS，深度过高导致延迟
HDD (7200RPM)8-3264-128mq-deadline / bfq低IOPS，深度过高无收益
RAID卡 (带缓存)64-256256-512mq-deadline依赖缓存策略，需实测
virtio-blk (虚拟机)64-256256-512none依赖宿主机能力

深度调优方法论：

  • 使用 fio --name=test --ioengine=libaio --iodepth=X 进行深度扫描
  • 监控 /sys/block/<dev>/inflight 观察实际飞行请求数
  • 结合 iostat -x 1 的 avgqu-sz 和 %util 判断深度是否合理
  • 对于延迟敏感场景，优先降低队列深度；对于吞吐量场景，适当提高深度

4.7 本章小结

请求队列是块设备层IO调度的核心数据结构，其设计直接影响系统的IO性能和资源利用率。理解 request_queue 的结构体布局、调度器挂载机制、sysfs参数接口以及队列深度控制策略，是进行存储场景优化的基础。在实际调优中，需要根据设备特性、负载模型和性能目标，动态调整队列参数以达到最佳效果。

← 上一章 📖 返回目录 下一章 →