Deadline IO 调度器可调参数

本小文件旨在阐述 Deadline IO 调度器的工作原理。特别是，它将阐明可能对高级用户有用的暴露出的可调参数的含义。

选择 IO 调度器

有关如何为每个设备选择 IO 调度器的信息，请参阅切换调度器。

---

read_expire（毫秒）

Deadline IO 调度器的目标是尝试保证请求的启动服务时间。由于我们主要关注读取延迟，因此这是可调的。当读取请求首次进入 IO 调度器时，它将被分配一个截止时间，该时间是当前时间加上以毫秒为单位的 read_expire 值。

write_expire（毫秒）

与上述 read_expire 类似，但适用于写入。

fifo_batch（请求数量）

请求按特定数据方向（读取或写入）分组为批次，并按扇区递增顺序提供服务。为限制额外寻道，只在批次之间检查截止时间。fifo_batch 控制每个批次的最大请求数量。

此参数调整了每个请求的延迟和总吞吐量之间的平衡。当低延迟是主要考虑因素时，值越小越好（其中值为 1 时，表现为先来先服务行为）。增加 fifo_batch 通常会提高吞吐量，但会牺牲延迟的稳定性。

writes_starved（调度次数）

当我们需要将请求从 IO 调度器队列移动到块设备调度队列时，我们总是优先处理读取请求。然而，我们也不希望无限期地饿死写入请求。因此，writes_starved 控制我们优先处理读取请求而不是写入请求的次数。当达到 writes_starved 次后，我们将根据与读取相同的标准调度一些写入请求。

front_merges（布尔值）

有时，一个新请求进入 IO 调度器，而该请求与队列中已有的请求是连续的。它可能接在该请求的尾部，也可能接在该请求的头部。这分别被称为“尾部合并候选项”或“头部合并候选项”。由于文件通常的布局方式，尾部合并比头部合并要常见得多。对于某些工作负载，您甚至可能知道花费时间尝试头部合并请求是浪费时间。将 front_merges 设置为 0 将禁用此功能。头部合并仍可能由于缓存的 last_merge 提示而发生，但由于其成本几乎为零，我们保留了此功能。当调用 IO 调度器合并函数时，我们只是禁用了红黑树（rbtree）的前扇区查找。

2002年11月11日, Jens Axboe <jens.axboe@oracle.com>