Deadline IO 调度器可调参数

这个小文件试图记录 deadline io 调度器的工作原理。特别是，它将阐明可能对高级用户感兴趣的公开可调参数的含义。

选择 IO 调度器

有关在每个设备上选择 io 调度器的信息，请参考 切换调度器。

---

read_expire（毫秒）

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

write_expire（毫秒）

与上面提到的 read_expire 类似，但用于写入。

fifo_batch（请求数量）

请求被分组为特定数据方向（读取或写入）的 批次，这些批次按扇区顺序递增进行服务。为了限制额外的寻道，仅在批次之间检查 deadline 过期。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>