Linux BFQ I/O 调度器完全指南Budget Fair Queueing 原理、参数调优与 cgroup 分组调度【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linuxBFQBudget Fair Queueing预算公平排队是 Linux 内核块层中一个按比例共享proportional-share带宽的 I/O 调度器在按权重分配设备带宽的同时为交互式与软实时应用提供低延迟保证。本文以内核源码树中的 Documentation/block/bfq-iosched.rst 为骨架结合 block/bfq-iosched.c、block/bfq-wf2q.c、block/bfq-cgroup.c 与 block/Kconfig.iosched 的源码实现系统讲解 BFQ 的工作机制、全部可调参数、sysfs 配置方法以及 cgroups-v1/v2 分组调度接口帮助读者根据自己的存储设备类型与负载特征在低延迟与高吞吐之间做出正确的取舍。1. BFQ 是什么定位与核心特性BFQ 是一个按比例共享带宽的 I/O 调度器并额外具备低延迟能力。除了支持 cgroupsblkio 或 io 控制器外它的两大核心特性是高系统/应用响应性为音频、视频播放器等时间敏感应用提供低延迟按带宽而非仅按时间分配在进程或组之间分配设备带宽当需要维持高吞吐时才切换回时间分配。在默认配置下BFQ优先保证延迟而非吞吐为了降低延迟BFQ 构建的调度可能以牺牲一定吞吐为代价。如果对某台设备的目标只是任何时候都追求最大吞吐就应该关闭所有低延迟启发式逻辑即把low_latency设为 0详见第 3 节关于延迟/吞吐取舍的配置说明。从内核配置来看BFQ 的启用开关位于 block/Kconfig.ioschedIOSCHED_BFQtristateBFQ I/O 调度器面向 blk-mqselect BLK_ICQ默认随内核配置启用BFQ_GROUP_IOSCHEDbooldepends on IOSCHED_BFQ BLK_CGROUP默认 y启用 BFQ 分层调度支持select BLK_CGROUP_RWSTATBFQ_CGROUP_DEBUGbooldepends on BFQ_GROUP_IOSCHED导出额外调试统计文件。1.1 调度开销BFQ 的代价和所有 I/O 调度器一样BFQ 会对每个 I/O 请求的处理增加开销。原文档给出了一组参考数据在 Intel Core i7-2760QM2.40GHz笔记本老 CPU上BFQ 受单锁保护的每请求处理总时间请求插入、派发、完成钩子执行时间之和约为1.9 微秒使用 S 套件的 throughput-sync.sh 脚本、性能剖析模式、简单代码插桩测得作为对比blk-mq 下最轻量的 mq-deadline 调度器每请求执行时间约为 0.7 微秒mq-deadline 约 800 行代码BFQ 约 10500 行。调度开销进一步限制了单个 CPU 能处理的最高 IOPS该上限同时受 I/O 栈其余部分执行开销限制。启用完整分层支持设置CONFIG_BFQ_GROUP_IOSCHED、不设置CONFIG_BFQ_CGROUP_DEBUG时三台典型设备上 BFQ 的可持续吞吐上限为CPU可持续吞吐上限KIOPSIntel i7-4850HQ400AMD A8-3850250ARM Cortex-A53 八核80若同时设置CONFIG_BFQ_CGROUP_DEBUG由于需要创建并持续更新所有blkio.bfq*统计文件上述上限分别下降为 310 / 200 / 56 KIOPS——统计更新的代价是相当可观的这是评估是否开启调试统计时必须考虑的因素。BFQ 同样适用于多队列multi-queue设备。2. 何时使用 BFQ个人系统与服务器系统的收益2.1 个人系统Personal systems交互应用的低延迟无论后台负载如何BFQ 都能保证交互任务获得存储设备近乎空闲般的响应速度。例如即使同时存在以下一种或多种后台负载一个或多个大文件的读、写或复制源码树的编译一台或多台虚拟机正在执行 I/O正在进行软件更新索引守护进程扫描文件系统并更新数据库启动应用或从应用内加载文件所花的时间仍与存储设备空闲时基本相同。作为对比同样的条件下使用 CFQ、NOOP 或 DEADLINE应用会经历高延迟甚至直到后台负载结束前都无响应SSD 上亦然。软实时应用的低延迟音频、视频播放器/流媒体等软实时应用无论后台 I/O 负载如何都能获得低延迟和低丢帧率几乎不会因后台负载出现卡顿。代码开发任务提速如果同时存在额外的负载BFQ 执行典型代码开发任务编译、checkout、merge 等的 I/O 相关部分会比 CFQ、NOOP 或 DEADLINE 快得多。高吞吐在机械硬盘上BFQ 相比 CFQ 最高可提升 30% 吞吐相比 DEADLINE 和 NOOP 最高可提升 150%针对测试中涉及的所有顺序负载对于随机负载以及闪存设备上的所有负载BFQ 与其他调度器的吞吐大致相当。强公平性与带宽/延迟保证BFQ 按权重、以任意负载和任意设备参数在 I/O 密集型应用之间按比例分配设备吞吐而不只是设备时间。由这些带宽保证可通过简单公式计算出每个 I/O 请求的紧致延迟上界。若未配置严格服务保证BFQ 只对那些若按带宽分配会导致吞吐损失的应用切换为基于时间的资源共享。2.2 服务器系统Server systems服务器端的大部分收益源于上述同样的服务特性。无论是否存在额外的、可能很重的负载BFQ 都能保证音频/视频流零或极低的抖动与丢帧率WEB 页面与内嵌对象的快速检索实时数据转储应用如数据包日志的实时记录服务器本地与远程访问的响应性。3. BFQ 工作原理预算、队列与调度算法BFQ 是一个按比例共享 I/O 调度器其总体结构以及大量代码继承自 CFQ。其核心机制如下队列与权重每个在设备上做 I/O 的进程都与一个权重和一个bfq_queueBFQ 队列关联BFQ 一次只授予一个队列进程独占访问设备的机会通过给每个队列关联一个**以扇区数计量的预算budget**来实现这一服务模型。预算消费与队列过期队列获得设备访问权后每派发一个请求就从该队列的预算中扣减相应请求大小只有当以下事件之一发生时在服务队列才会被过期expire即服务被挂起队列用完预算队列变空**预算超时budget timeout**触发——该超时机制防止做随机 I/O 的进程长时间占用设备而大幅降低吞吐。设备空转device idling与 CFQ 相同发出同步请求的进程所关联的队列在变空时不会立即被过期。相反BFQ 可能会让设备空转一小段时间给进程机会如果它及时发出新请求就能继续被服务。设备空转通常在旋转设备以及不支持命令排队的闪存设备上提升做同步顺序 I/O 进程的吞吐。此外在 BFQ 下设备空转还是保证发出同步请求的进程获得其应得吞吐份额的关键手段详见slice_idle参数说明。关于空转的几个重要事实若多个进程同时竞争设备但权重相同BFQ 可以在完全不空转的情况下保证预期的吞吐分配因此这一常见场景下吞吐尽可能高在带有内部命令排队典型如 NCQ的闪存存储上设备空转总是有害于吞吐因此 BFQ 只在这些设备上严格出于服务保证需要保证低延迟或公平性时才空转此时整体吞吐可能次优。目前尚无方案能在内部排队设备上同时提供强服务保证与最优吞吐BFQ 会自动对突发创建的队列关闭空转——这类队列通常关联应用/服务的进程它们最受益于高吞吐典型例子是启动期间的 systemd、以及git grep。weight-raising权重提升若低延迟模式已启用默认配置BFQ 会执行一些特殊启发式逻辑来识别交互式与软实时应用如视频/音频播放器/流媒体并降低它们的延迟。为此最重要的动作是给这些应用关联的队列超过其应得份额的设备吞吐。BFQ 为交互式应用提供较温和的 weight-raising为软实时应用提供更强的形式。在源码中关闭low_latency时会调用bfq_end_wr()结束所有 weight-raising 状态见 block/bfq-iosched.c。早期队列合并Early Queue Merge, EQM与 CFQ 一样BFQ 会合并执行交错 I/O 的队列即随机 I/O 合并后变成近似顺序 I/O。与 CFQ 不同的是BFQ 用一种响应更快的机制——EQM来实现EQM 对交错 I/O协作进程的检测极其灵敏使得 BFQ 仅靠队列合并就能获得高吞吐而 CFQ 在这种场景下还需要借助抢占机制。因此 EQM 是在交错 I/O 下获得高吞吐的统一机制。B-WF2Q 调度与预算无关性队列按B-WF2Q一种 WF2Q 变体调度使用增强型红黑树实现保持整体 O(log N) 复杂度并天然支持分层调度第 4 节。B-WF2Q 保证与理想、完全公平、平滑服务的偏差很小即使吞吐发生波动每个队列也能获得与其权重成正比的吞吐份额且与设备参数、当前负载、所分配的预算均无关。这种预算无关性看似反直觉实则非常有益任何比例共享调度器中与理想服务的最大偏差正比于分配给队列的最大预算slice。BFQ 不仅能靠 B-WF2Q 的精确服务收紧偏差而且不需要为了给队列更高吞吐份额而分配更大预算BFQ 可以自由地为每个进程队列选择最贴合其需求、或最能利用其 I/O 模式的预算。特别是BFQ 用一个简单的反馈回路算法在队列过期时更新其下一个预算对做顺序 I/O 的 I/O 密集型应用最终分配大预算——它们获得设备访问权后服务时间越长吞吐越高对时间敏感型应用通常做零星、短促 I/O最终分配小预算——等待服务的队列预算越小B-WF2Q 就越快轮询到它。抢占与 ioprio 类当多个进程同时竞争设备但权重全部相同时BFQ 在永不空转的情况下仍能保证预期吞吐分配——它改用抢占机制这一常见场景下吞吐因此高得多。ioprio 类按严格优先级顺序服务只要存在更高优先级的队列低优先级队列就不会被服务。同一类内的队列之间带宽按各自权重比例分配。不过 Idle 类仍被保证一小条额外带宽以防饥饿。4. BFQ 的全部可调参数与配置方法大多数 BFQ 可调参数影响服务保证主要是延迟与公平性和吞吐。想要在两者之间做出理想的取舍重点看slice_idle、strict_guarantees、low_latency三个参数想要最大化吞吐重点看slice_idle、timeout_sync、max_budget。其余性能相关参数继承自 CFQ主要为兼容性保留——迄今没有任何报告显示修改这些参数能在 BFQ 中带来性能提升。其中back_seek_max、back_seek_penalty、fifo_expire_async、fifo_expire_sync与 CFQ 完全相同描述直接沿用 CFQslice_idle描述中的部分考虑也沿自 CFQ。4.1 每个进程的 ioprio 与权重不使用 cgroups 接口时见第 5 节权重只能通过 I/O 优先级间接分配关系为weight (IOPRIO_BE_NR - ioprio) * 10源码中的实现位于 block/bfq-wf2q.cunsigned short bfq_ioprio_to_weight(int ioprio) { return (IOPRIO_NR_LEVELS - ioprio) * BFQ_WEIGHT_CONVERSION_COEFF; }其中IOPRIO_NR_LEVELS为 8、BFQ_WEIGHT_CONVERSION_COEFF为 10即 ioprio 0→80、ioprio 7→10。注意若low_latency开启BFQ 会自动提升交互式与软实时应用关联队列的权重如果需要/想要自己控制权重请关闭该参数见 4.8。4.2 slice_idle该参数指定某些同步 BFQ 队列变空后BFQ 为等待下一个 I/O 请求应空转多长时间。默认slice_idle为非零值。空转有双重目的提升吞吐与确保预期的吞吐分布得到遵守。就吞吐而言在寻道代价高的介质如单主轴 SATA/SAS 盘上空转能减少总体寻道次数、改善吞吐。将slice_idle设为 0 会移除所有队列上的空转在更快存储设备如硬件 RAID 配置中的多块 SATA/SAS 盘以及带内部命令排队和并行能力的闪存存储上通常能看到整体吞吐改善。因此是否设置slice_idle0取决于存储与负载SATA/SAS 盘、SATA/SAS 盘的软件 RAID通常保持空转slice_idle开启有益单个 LUN 背后有多个主轴主机端硬件 RAID 控制器或存储阵列、或闪存快速存储设置slice_idle0可能获得更好吞吐且延迟可接受。然而在权重不同或请求长度不同的情况下空转是执行服务保证所必需的。原因在于假设队列 A 每被服务一次必须获得多个 I/O 请求服务、而队列 B 只需一个。空转确保A 变空后稍晚才发出新请求时不会有 B 的请求插入中间从而 A 不会失去在 B 的下一个请求之前多派发几个请求的机会。注意空转只在请求派发层面保证队列的差异化对待要保证实际服务顺序与派发顺序一致还必须设置strict_guarantees。空转也有严重的另一面除了上述同样有益于吞吐的情况外空转可能严重损害吞吐典型场景是随机负载。为此 BFQ 倾向于在空转同样有益于吞吐的场景之外尽量少空转第 3 节已详述。这一行为加上strict_guarantees相关的其他问题会导致短期服务保证偶尔被违反。而在某些场景下这些保证比最大吞吐更重要例如视频播放/流媒体中低丢帧率可能比最大吞吐更重要此时应考虑设置strict_guarantees。4.3 slice_idle_us与slice_idle控制同一个调优参数但单位是微秒。两个可调项都可用来设置空转行为设置其中一个后另一个会在 sysfs 中反映出新值。源码实现中二者共享同一个变量bfqd-bfq_slice_idleslice_idle按毫秒换算STORE_FUNCTION的__CONV 2即data * NSEC_PER_MSECslice_idle_us按微秒换算USEC_STORE_FUNCTION即data * NSEC_PER_USEC见 block/bfq-iosched.c。默认值bfq_slice_idle NSEC_PER_SEC / 125即8msblock/bfq-iosched.c。4.4 strict_guarantees若设置该参数默认不设置BFQ 会在服务中的队列变空时总是执行空转强制设备一次只服务一个 I/O 请求只有没有未完成请求时才派发新请求。在权重或请求大小有差异时上述两个条件都是保证每个 BFQ 队列获得其应得带宽份额所必需的第一个条件的必要性见slice_idle说明第二个条件是因为所有现代存储设备都会对内部排队的请求进行重排可能轻易破坏 I/O 调度器执行的服务保证。设置strict_guarantees显然可能影响吞吐。源码中还体现了一个细节启用strict_guarantees时如果当前bfq_slice_idle小于 8ms内核会自动将其抬升到 8msblock/bfq-iosched.c以保证空转行为足以支撑严格保证。4.5 back_seek_max指定单位为Kbytes向后寻道的最大距离——距离指从当前磁头位置到在距离上位于其后方的扇区之间的空间量。该参数让调度器可以提前考虑向后方向的请求只要请求与当前磁头位置的距离在此范围内就可将其视作下一个请求。4.6 back_seek_penalty用于计算向后寻道代价的参数。如果某请求的向后距离只是某个前方请求的1/back_seek_penalty则两个请求的寻道代价视为等价——这样调度器就不会偏向其中任何一个否则会偏向前方请求。默认值为2。4.7 fifo_expire_async 与 fifo_expire_syncfifo_expire_async异步请求的超时时间默认250msfifo_expire_sync同步请求的超时时间默认125ms。若要偏向同步请求应相对fifo_expire_async减小此值。源码中的默认值定义为bfq_fifo_expire[2] { NSEC_PER_SEC / 4, NSEC_PER_SEC / 8 }block/bfq-iosched.c即 async250ms、sync125ms请求入队时会依据请求是否同步打上fifo_time截止时间戳block/bfq-iosched.c。4.8 low_latency用于启用/禁用 BFQ 的低延迟模式默认启用。启用时交互式与软实时应用获得特权、体验更低延迟机制见第 3 节。两种必须关闭此模式的场景需要完全控制带宽分配时启用状态下 BFQ 会自动提高特权应用的带宽份额作为保证其低延迟的主要手段唯一目标是高吞吐时为部分应用的特权化 I/O 可能带来吞吐下降。要在非旋转设备上达到最高吞吐可能还需要把slice_idle设为 0代价是放弃公平性与低延迟方面的任何强保证。4.9 timeout_sync队列一旦被选中服务能被给予的最大设备时间。在寻道代价高的设备上增大该值通常能提高最大吞吐反之增大会使短期带宽与延迟保证的粒度变粗尤其当下一参数为 0 时。源码中默认值bfq_timeout HZ / 8即125msblock/bfq-iosched.c且写入时按毫秒转 jiffiesmsecs_to_jiffies。4.10 max_budget队列一旦进入服务能被提供的最大服务量以扇区计当然受上述超时限制。根据算法描述更大的值会按顺序 I/O 请求占比成比例地提高吞吐代价是使短期带宽与延迟保证的粒度变粗。默认值为0表示启用自动调优BFQ 根据估计的峰值速率把max_budget设置为timeout_sync期间最多可服务的扇区数。源码中对应bfq_calc_max_budget()与bfq_max_budget()自动调优模式下bfq_max_budget动态重算用户显式设置时使用用户值未启用任何时回退到常量bfq_default_max_budget 16 * 102416384 扇区block/bfq-iosched.c。写入max_budget0会立即用bfq_calc_max_budget()重新计算block/bfq-iosched.c。有用户曾在特定设备上报称显式设置max_budget即设为大于 0 的值且比 BFQ 自动调优得到的值更高能达到更高吞吐。另一种等效做法是只增大timeout_sync、让max_budget保持 0——此时内核同样会重新计算max_budgetblock/bfq-iosched.c。4.11 sysfs 接口一览所有参数都通过块设备对应的电梯elevatorsysfs 属性暴露。源码中bfq_attrs[]注册了以下属性block/bfq-iosched.cfifo_expire_sync fifo_expire_async back_seek_max back_seek_penalty slice_idle slice_idle_us max_budget timeout_sync strict_guarantees low_latency典型配置命令以设备/dev/sda为例# 查看当前 BFQ 调度器参数 cat /sys/block/sda/queue/iosched/low_latency # 关闭低延迟模式追求最大吞吐 echo 0 /sys/block/sda/queue/iosched/low_latency # 关闭设备空转闪存/硬件 RAID 场景 echo 0 /sys/block/sda/queue/iosched/slice_idle # 单位为微秒的等价写法 echo 0 /sys/block/sda/queue/iosched/slice_idle_us # 显式指定最大预算扇区0 表示自动调优 echo 0 /sys/block/sda/queue/iosched/max_budget # 开启严格服务保证注意会强制 slice_idle 8ms echo 1 /sys/block/sda/queue/iosched/strict_guarantees从 block/Kconfig.iosched 的说明可知BFQ 通过 blk-mq 的电梯框架注册iosched_bfq_mq见 block/bfq-iosched.c将 BFQ 设置为活动调度器通常使用echo bfq /sys/block/sda/queue/scheduler5. BFQ 的 cgroup 分组调度BFQ 同时支持 cgroups-v1 和 cgroups-v2 的 io 控制器分别叫blkio与io并提供基于权重的比例共享。要激活 cgroups 支持需在内核配置中设置BFQ_GROUP_IOSCHED见 block/Kconfig.iosched。5.1 提供的服务保证BFQ 下的比例共享意味着真正的设备带宽比例共享按组权重分配。例如权重 200 的组获得的带宽是权重 100 的组的两倍而不仅仅是两倍的时间。BFQ 支持任意深度的层次结构组树。带宽按预期方式在组与进程之间分配对每个组而言其子组按各自权重共享该组的全部带宽。特别地对每个叶子组组内每个进程获得整个组带宽的相同份额除非修改了该进程的 ioprio。组或进程的资源共享保证可能部分或全部从带宽切换到时间当为该组提供带宽保证会导致吞吐下降太多时会发生切换。该切换逐进程进行若叶子组中某进程按带宽份额被服务会导致吞吐损失则 BFQ 只对该进程回退为基于时间的比例共享。5.2 接口与统计文件要让 BFQ 为某设备提供带宽比例共享BFQ 当然必须是该设备的活动调度器。在每个组目录内BFQ 专属的 cgroup 参数与统计文件以bfq.前缀开头。因此 cgroups-v1 的完整前缀是blkio.bfq.、cgroups-v2 是io.bfq.。例如设置组权重的参数是blkio.bfq.weight或io.bfq.weight。cgroups-v1blkio 控制器下的统计文件BFQ 创建并维护的统计文件集合取决于是否设置CONFIG_BFQ_CGROUP_DEBUG若设置CONFIG_BFQ_CGROUP_DEBUGBFQ 创建 Documentation/admin-guide/cgroup-v1/blkio-controller.rst 中记载的全部统计文件若未设置BFQ 只创建以下四个文件blkio.bfq.io_service_bytes blkio.bfq.io_service_bytes_recursive blkio.bfq.io_serviced blkio.bfq.io_serviced_recursive源码中bfq_blkcg_legacy_files[]完整定义了 cgroups-v1 的文件集block/bfq-cgroup.c基础统计为bfq.io_service_bytes读写字节数与bfq.io_serviced读写请求数以及它们的_recursive覆盖组及其后代版本调试统计#ifdef CONFIG_BFQ_CGROUP_DEBUG还包括bfq.time、bfq.sectors、bfq.io_service_time、bfq.io_wait_time、bfq.io_merged、bfq.io_queued及其_recursive版本以及bfq.avg_queue_size、bfq.group_wait_time、bfq.idle_time、bfq.empty_time、bfq.dequeue。cgroups-v2 侧则只暴露bfq.weightbfq_blkg_files[]block/bfq-cgroup.c。CONFIG_BFQ_CGROUP_DEBUG的取值极大地影响 BFQ 可持续的最大吞吐因为更新blkio.bfq.*统计相当昂贵尤其是一些由该选项启用的统计项第 1.1 节的对比数据即为明证。5.3 可设置的参数对每个组可设置以下参数weight该 cgroup 在其父组内部的默认权重可选值1..1000默认100cgroups-v1写入blkio.bfq.weightcgroups-v2写入io.bfq.weight可带可选前缀default加空格第 4.1 节描述的 ioprio 与权重之间的线性映射仍然有效但所有高于IOPRIO_BE_NR * 10的权重都被映射为 ioprio 0再次提醒若low_latency开启BFQ 会自动提升交互式与软实时应用关联队列的权重要自己控制权重请关闭该参数。weight_device为该 cgroup 指定按设备的权重语法minor:major weight写入权重0可重置为默认权重cgroups-v1写入blkio.bfq.weight_devicecgroups-v2文件名为io.bfq.weight。5.4 使用示例# ---- cgroups-v1 ---- # 在 /sys/fs/cgroup/blkio 下为 groupA 设置权重 200 echo 200 /sys/fs/cgroup/blkio/groupA/blkio.bfq.weight # 为特定设备主:次 8:0设置权重 300 echo 8:0 300 /sys/fs/cgroup/blkio/groupA/blkio.bfq.weight_device # 将进程 PID 移入该组 echo $PID /sys/fs/cgroup/blkio/groupA/tasks # 查看 BFQ 基本统计 cat /sys/fs/cgroup/blkio/groupA/blkio.bfq.io_service_bytes cat /sys/fs/cgroup/blkio/groupA/blkio.bfq.io_serviced_recursive # ---- cgroups-v2 ---- # 启用 io 控制器后需先 enable设置默认权重 echo default 200 /sys/fs/cgroup/groupA/io.bfq.weight # 为设备 8:0 设置权重 300io.bfq.weight 即 weight_device 语义 echo 8:0 300 /sys/fs/cgroup/groupA/io.bfq.weight # 将进程移入组cgroups-v2 通过 cgroup.procs / cgroup.threads echo $PID /sys/fs/cgroup/groupA/cgroup.procs6. 典型配置场景速查目标推荐配置代价桌面/交互应用低延迟保持默认low_latency1、slice_idle非零可能牺牲一定吞吐软实时音视频播放/流媒体低丢帧默认基础上开启strict_guarantees1吞吐明显下降最大吞吐闪存/硬件 RAIDlow_latency0、slice_idle0放弃公平性与低延迟强保证机械盘顺序负载高吞吐保持slice_idle开启可增大timeout_sync短期保证粒度变粗显式预算调优max_budgetNN0或增大timeout_sync保持max_budget0需按设备实测多租户带宽隔离启用BFQ_GROUP_IOSCHED按组设置weight/weight_device调度开销随组层次增加7. 进一步阅读与源码入口官方内核文档本文骨架Documentation/block/bfq-iosched.rst核心调度器实现block/bfq-iosched.c约 7678 行含全部 sysfs 参数定义与 store/show 函数调度树算法 B-WF2Qblock/bfq-wf2q.c含bfq_ioprio_to_weight权重映射实现头文件与结构定义block/bfq-iosched.hcgroup 接口实现block/bfq-cgroup.cbfq_blkcg_legacy_files[]与bfq_blkg_files[]内核配置选项block/Kconfig.iosched通用 cgroup-v1 blkio 控制器文档Documentation/admin-guide/cgroup-v1/blkio-controller.rst需要注意的是本文描述的参数默认值与取值范围均以当前内核源码树block/bfq-iosched.c为准slice_idle默认 8ms、可设范围 [0, INT_MAX] msfifo_expire_sync/async默认 125/250ms、最小 1msback_seek_penalty默认 2、最小 1timeout_sync默认 125ms、最小 1mslow_latency与strict_guarantees为布尔量0/1。不同内核版本间默认值可能略有差异实际部署时请以目标内核的 sysfs 输出为准。【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Linux BFQ I/O 调度器完全指南：Budget Fair Queueing 原理、参数调优与 cgroup 分组调度
Linux BFQ I/O 调度器完全指南Budget Fair Queueing 原理、参数调优与 cgroup 分组调度【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linuxBFQBudget Fair Queueing预算公平排队是 Linux 内核块层中一个按比例共享proportional-share带宽的 I/O 调度器在按权重分配设备带宽的同时为交互式与软实时应用提供低延迟保证。本文以内核源码树中的 Documentation/block/bfq-iosched.rst 为骨架结合 block/bfq-iosched.c、block/bfq-wf2q.c、block/bfq-cgroup.c 与 block/Kconfig.iosched 的源码实现系统讲解 BFQ 的工作机制、全部可调参数、sysfs 配置方法以及 cgroups-v1/v2 分组调度接口帮助读者根据自己的存储设备类型与负载特征在低延迟与高吞吐之间做出正确的取舍。1. BFQ 是什么定位与核心特性BFQ 是一个按比例共享带宽的 I/O 调度器并额外具备低延迟能力。除了支持 cgroupsblkio 或 io 控制器外它的两大核心特性是高系统/应用响应性为音频、视频播放器等时间敏感应用提供低延迟按带宽而非仅按时间分配在进程或组之间分配设备带宽当需要维持高吞吐时才切换回时间分配。在默认配置下BFQ优先保证延迟而非吞吐为了降低延迟BFQ 构建的调度可能以牺牲一定吞吐为代价。如果对某台设备的目标只是任何时候都追求最大吞吐就应该关闭所有低延迟启发式逻辑即把low_latency设为 0详见第 3 节关于延迟/吞吐取舍的配置说明。从内核配置来看BFQ 的启用开关位于 block/Kconfig.ioschedIOSCHED_BFQtristateBFQ I/O 调度器面向 blk-mqselect BLK_ICQ默认随内核配置启用BFQ_GROUP_IOSCHEDbooldepends on IOSCHED_BFQ BLK_CGROUP默认 y启用 BFQ 分层调度支持select BLK_CGROUP_RWSTATBFQ_CGROUP_DEBUGbooldepends on BFQ_GROUP_IOSCHED导出额外调试统计文件。1.1 调度开销BFQ 的代价和所有 I/O 调度器一样BFQ 会对每个 I/O 请求的处理增加开销。原文档给出了一组参考数据在 Intel Core i7-2760QM2.40GHz笔记本老 CPU上BFQ 受单锁保护的每请求处理总时间请求插入、派发、完成钩子执行时间之和约为1.9 微秒使用 S 套件的 throughput-sync.sh 脚本、性能剖析模式、简单代码插桩测得作为对比blk-mq 下最轻量的 mq-deadline 调度器每请求执行时间约为 0.7 微秒mq-deadline 约 800 行代码BFQ 约 10500 行。调度开销进一步限制了单个 CPU 能处理的最高 IOPS该上限同时受 I/O 栈其余部分执行开销限制。启用完整分层支持设置CONFIG_BFQ_GROUP_IOSCHED、不设置CONFIG_BFQ_CGROUP_DEBUG时三台典型设备上 BFQ 的可持续吞吐上限为CPU可持续吞吐上限KIOPSIntel i7-4850HQ400AMD A8-3850250ARM Cortex-A53 八核80若同时设置CONFIG_BFQ_CGROUP_DEBUG由于需要创建并持续更新所有blkio.bfq*统计文件上述上限分别下降为 310 / 200 / 56 KIOPS——统计更新的代价是相当可观的这是评估是否开启调试统计时必须考虑的因素。BFQ 同样适用于多队列multi-queue设备。2. 何时使用 BFQ个人系统与服务器系统的收益2.1 个人系统Personal systems交互应用的低延迟无论后台负载如何BFQ 都能保证交互任务获得存储设备近乎空闲般的响应速度。例如即使同时存在以下一种或多种后台负载一个或多个大文件的读、写或复制源码树的编译一台或多台虚拟机正在执行 I/O正在进行软件更新索引守护进程扫描文件系统并更新数据库启动应用或从应用内加载文件所花的时间仍与存储设备空闲时基本相同。作为对比同样的条件下使用 CFQ、NOOP 或 DEADLINE应用会经历高延迟甚至直到后台负载结束前都无响应SSD 上亦然。软实时应用的低延迟音频、视频播放器/流媒体等软实时应用无论后台 I/O 负载如何都能获得低延迟和低丢帧率几乎不会因后台负载出现卡顿。代码开发任务提速如果同时存在额外的负载BFQ 执行典型代码开发任务编译、checkout、merge 等的 I/O 相关部分会比 CFQ、NOOP 或 DEADLINE 快得多。高吞吐在机械硬盘上BFQ 相比 CFQ 最高可提升 30% 吞吐相比 DEADLINE 和 NOOP 最高可提升 150%针对测试中涉及的所有顺序负载对于随机负载以及闪存设备上的所有负载BFQ 与其他调度器的吞吐大致相当。强公平性与带宽/延迟保证BFQ 按权重、以任意负载和任意设备参数在 I/O 密集型应用之间按比例分配设备吞吐而不只是设备时间。由这些带宽保证可通过简单公式计算出每个 I/O 请求的紧致延迟上界。若未配置严格服务保证BFQ 只对那些若按带宽分配会导致吞吐损失的应用切换为基于时间的资源共享。2.2 服务器系统Server systems服务器端的大部分收益源于上述同样的服务特性。无论是否存在额外的、可能很重的负载BFQ 都能保证音频/视频流零或极低的抖动与丢帧率WEB 页面与内嵌对象的快速检索实时数据转储应用如数据包日志的实时记录服务器本地与远程访问的响应性。3. BFQ 工作原理预算、队列与调度算法BFQ 是一个按比例共享 I/O 调度器其总体结构以及大量代码继承自 CFQ。其核心机制如下队列与权重每个在设备上做 I/O 的进程都与一个权重和一个bfq_queueBFQ 队列关联BFQ 一次只授予一个队列进程独占访问设备的机会通过给每个队列关联一个**以扇区数计量的预算budget**来实现这一服务模型。预算消费与队列过期队列获得设备访问权后每派发一个请求就从该队列的预算中扣减相应请求大小只有当以下事件之一发生时在服务队列才会被过期expire即服务被挂起队列用完预算队列变空**预算超时budget timeout**触发——该超时机制防止做随机 I/O 的进程长时间占用设备而大幅降低吞吐。设备空转device idling与 CFQ 相同发出同步请求的进程所关联的队列在变空时不会立即被过期。相反BFQ 可能会让设备空转一小段时间给进程机会如果它及时发出新请求就能继续被服务。设备空转通常在旋转设备以及不支持命令排队的闪存设备上提升做同步顺序 I/O 进程的吞吐。此外在 BFQ 下设备空转还是保证发出同步请求的进程获得其应得吞吐份额的关键手段详见slice_idle参数说明。关于空转的几个重要事实若多个进程同时竞争设备但权重相同BFQ 可以在完全不空转的情况下保证预期的吞吐分配因此这一常见场景下吞吐尽可能高在带有内部命令排队典型如 NCQ的闪存存储上设备空转总是有害于吞吐因此 BFQ 只在这些设备上严格出于服务保证需要保证低延迟或公平性时才空转此时整体吞吐可能次优。目前尚无方案能在内部排队设备上同时提供强服务保证与最优吞吐BFQ 会自动对突发创建的队列关闭空转——这类队列通常关联应用/服务的进程它们最受益于高吞吐典型例子是启动期间的 systemd、以及git grep。weight-raising权重提升若低延迟模式已启用默认配置BFQ 会执行一些特殊启发式逻辑来识别交互式与软实时应用如视频/音频播放器/流媒体并降低它们的延迟。为此最重要的动作是给这些应用关联的队列超过其应得份额的设备吞吐。BFQ 为交互式应用提供较温和的 weight-raising为软实时应用提供更强的形式。在源码中关闭low_latency时会调用bfq_end_wr()结束所有 weight-raising 状态见 block/bfq-iosched.c。早期队列合并Early Queue Merge, EQM与 CFQ 一样BFQ 会合并执行交错 I/O 的队列即随机 I/O 合并后变成近似顺序 I/O。与 CFQ 不同的是BFQ 用一种响应更快的机制——EQM来实现EQM 对交错 I/O协作进程的检测极其灵敏使得 BFQ 仅靠队列合并就能获得高吞吐而 CFQ 在这种场景下还需要借助抢占机制。因此 EQM 是在交错 I/O 下获得高吞吐的统一机制。B-WF2Q 调度与预算无关性队列按B-WF2Q一种 WF2Q 变体调度使用增强型红黑树实现保持整体 O(log N) 复杂度并天然支持分层调度第 4 节。B-WF2Q 保证与理想、完全公平、平滑服务的偏差很小即使吞吐发生波动每个队列也能获得与其权重成正比的吞吐份额且与设备参数、当前负载、所分配的预算均无关。这种预算无关性看似反直觉实则非常有益任何比例共享调度器中与理想服务的最大偏差正比于分配给队列的最大预算slice。BFQ 不仅能靠 B-WF2Q 的精确服务收紧偏差而且不需要为了给队列更高吞吐份额而分配更大预算BFQ 可以自由地为每个进程队列选择最贴合其需求、或最能利用其 I/O 模式的预算。特别是BFQ 用一个简单的反馈回路算法在队列过期时更新其下一个预算对做顺序 I/O 的 I/O 密集型应用最终分配大预算——它们获得设备访问权后服务时间越长吞吐越高对时间敏感型应用通常做零星、短促 I/O最终分配小预算——等待服务的队列预算越小B-WF2Q 就越快轮询到它。抢占与 ioprio 类当多个进程同时竞争设备但权重全部相同时BFQ 在永不空转的情况下仍能保证预期吞吐分配——它改用抢占机制这一常见场景下吞吐因此高得多。ioprio 类按严格优先级顺序服务只要存在更高优先级的队列低优先级队列就不会被服务。同一类内的队列之间带宽按各自权重比例分配。不过 Idle 类仍被保证一小条额外带宽以防饥饿。4. BFQ 的全部可调参数与配置方法大多数 BFQ 可调参数影响服务保证主要是延迟与公平性和吞吐。想要在两者之间做出理想的取舍重点看slice_idle、strict_guarantees、low_latency三个参数想要最大化吞吐重点看slice_idle、timeout_sync、max_budget。其余性能相关参数继承自 CFQ主要为兼容性保留——迄今没有任何报告显示修改这些参数能在 BFQ 中带来性能提升。其中back_seek_max、back_seek_penalty、fifo_expire_async、fifo_expire_sync与 CFQ 完全相同描述直接沿用 CFQslice_idle描述中的部分考虑也沿自 CFQ。4.1 每个进程的 ioprio 与权重不使用 cgroups 接口时见第 5 节权重只能通过 I/O 优先级间接分配关系为weight (IOPRIO_BE_NR - ioprio) * 10源码中的实现位于 block/bfq-wf2q.cunsigned short bfq_ioprio_to_weight(int ioprio) { return (IOPRIO_NR_LEVELS - ioprio) * BFQ_WEIGHT_CONVERSION_COEFF; }其中IOPRIO_NR_LEVELS为 8、BFQ_WEIGHT_CONVERSION_COEFF为 10即 ioprio 0→80、ioprio 7→10。注意若low_latency开启BFQ 会自动提升交互式与软实时应用关联队列的权重如果需要/想要自己控制权重请关闭该参数见 4.8。4.2 slice_idle该参数指定某些同步 BFQ 队列变空后BFQ 为等待下一个 I/O 请求应空转多长时间。默认slice_idle为非零值。空转有双重目的提升吞吐与确保预期的吞吐分布得到遵守。就吞吐而言在寻道代价高的介质如单主轴 SATA/SAS 盘上空转能减少总体寻道次数、改善吞吐。将slice_idle设为 0 会移除所有队列上的空转在更快存储设备如硬件 RAID 配置中的多块 SATA/SAS 盘以及带内部命令排队和并行能力的闪存存储上通常能看到整体吞吐改善。因此是否设置slice_idle0取决于存储与负载SATA/SAS 盘、SATA/SAS 盘的软件 RAID通常保持空转slice_idle开启有益单个 LUN 背后有多个主轴主机端硬件 RAID 控制器或存储阵列、或闪存快速存储设置slice_idle0可能获得更好吞吐且延迟可接受。然而在权重不同或请求长度不同的情况下空转是执行服务保证所必需的。原因在于假设队列 A 每被服务一次必须获得多个 I/O 请求服务、而队列 B 只需一个。空转确保A 变空后稍晚才发出新请求时不会有 B 的请求插入中间从而 A 不会失去在 B 的下一个请求之前多派发几个请求的机会。注意空转只在请求派发层面保证队列的差异化对待要保证实际服务顺序与派发顺序一致还必须设置strict_guarantees。空转也有严重的另一面除了上述同样有益于吞吐的情况外空转可能严重损害吞吐典型场景是随机负载。为此 BFQ 倾向于在空转同样有益于吞吐的场景之外尽量少空转第 3 节已详述。这一行为加上strict_guarantees相关的其他问题会导致短期服务保证偶尔被违反。而在某些场景下这些保证比最大吞吐更重要例如视频播放/流媒体中低丢帧率可能比最大吞吐更重要此时应考虑设置strict_guarantees。4.3 slice_idle_us与slice_idle控制同一个调优参数但单位是微秒。两个可调项都可用来设置空转行为设置其中一个后另一个会在 sysfs 中反映出新值。源码实现中二者共享同一个变量bfqd-bfq_slice_idleslice_idle按毫秒换算STORE_FUNCTION的__CONV 2即data * NSEC_PER_MSECslice_idle_us按微秒换算USEC_STORE_FUNCTION即data * NSEC_PER_USEC见 block/bfq-iosched.c。默认值bfq_slice_idle NSEC_PER_SEC / 125即8msblock/bfq-iosched.c。4.4 strict_guarantees若设置该参数默认不设置BFQ 会在服务中的队列变空时总是执行空转强制设备一次只服务一个 I/O 请求只有没有未完成请求时才派发新请求。在权重或请求大小有差异时上述两个条件都是保证每个 BFQ 队列获得其应得带宽份额所必需的第一个条件的必要性见slice_idle说明第二个条件是因为所有现代存储设备都会对内部排队的请求进行重排可能轻易破坏 I/O 调度器执行的服务保证。设置strict_guarantees显然可能影响吞吐。源码中还体现了一个细节启用strict_guarantees时如果当前bfq_slice_idle小于 8ms内核会自动将其抬升到 8msblock/bfq-iosched.c以保证空转行为足以支撑严格保证。4.5 back_seek_max指定单位为Kbytes向后寻道的最大距离——距离指从当前磁头位置到在距离上位于其后方的扇区之间的空间量。该参数让调度器可以提前考虑向后方向的请求只要请求与当前磁头位置的距离在此范围内就可将其视作下一个请求。4.6 back_seek_penalty用于计算向后寻道代价的参数。如果某请求的向后距离只是某个前方请求的1/back_seek_penalty则两个请求的寻道代价视为等价——这样调度器就不会偏向其中任何一个否则会偏向前方请求。默认值为2。4.7 fifo_expire_async 与 fifo_expire_syncfifo_expire_async异步请求的超时时间默认250msfifo_expire_sync同步请求的超时时间默认125ms。若要偏向同步请求应相对fifo_expire_async减小此值。源码中的默认值定义为bfq_fifo_expire[2] { NSEC_PER_SEC / 4, NSEC_PER_SEC / 8 }block/bfq-iosched.c即 async250ms、sync125ms请求入队时会依据请求是否同步打上fifo_time截止时间戳block/bfq-iosched.c。4.8 low_latency用于启用/禁用 BFQ 的低延迟模式默认启用。启用时交互式与软实时应用获得特权、体验更低延迟机制见第 3 节。两种必须关闭此模式的场景需要完全控制带宽分配时启用状态下 BFQ 会自动提高特权应用的带宽份额作为保证其低延迟的主要手段唯一目标是高吞吐时为部分应用的特权化 I/O 可能带来吞吐下降。要在非旋转设备上达到最高吞吐可能还需要把slice_idle设为 0代价是放弃公平性与低延迟方面的任何强保证。4.9 timeout_sync队列一旦被选中服务能被给予的最大设备时间。在寻道代价高的设备上增大该值通常能提高最大吞吐反之增大会使短期带宽与延迟保证的粒度变粗尤其当下一参数为 0 时。源码中默认值bfq_timeout HZ / 8即125msblock/bfq-iosched.c且写入时按毫秒转 jiffiesmsecs_to_jiffies。4.10 max_budget队列一旦进入服务能被提供的最大服务量以扇区计当然受上述超时限制。根据算法描述更大的值会按顺序 I/O 请求占比成比例地提高吞吐代价是使短期带宽与延迟保证的粒度变粗。默认值为0表示启用自动调优BFQ 根据估计的峰值速率把max_budget设置为timeout_sync期间最多可服务的扇区数。源码中对应bfq_calc_max_budget()与bfq_max_budget()自动调优模式下bfq_max_budget动态重算用户显式设置时使用用户值未启用任何时回退到常量bfq_default_max_budget 16 * 102416384 扇区block/bfq-iosched.c。写入max_budget0会立即用bfq_calc_max_budget()重新计算block/bfq-iosched.c。有用户曾在特定设备上报称显式设置max_budget即设为大于 0 的值且比 BFQ 自动调优得到的值更高能达到更高吞吐。另一种等效做法是只增大timeout_sync、让max_budget保持 0——此时内核同样会重新计算max_budgetblock/bfq-iosched.c。4.11 sysfs 接口一览所有参数都通过块设备对应的电梯elevatorsysfs 属性暴露。源码中bfq_attrs[]注册了以下属性block/bfq-iosched.cfifo_expire_sync fifo_expire_async back_seek_max back_seek_penalty slice_idle slice_idle_us max_budget timeout_sync strict_guarantees low_latency典型配置命令以设备/dev/sda为例# 查看当前 BFQ 调度器参数 cat /sys/block/sda/queue/iosched/low_latency # 关闭低延迟模式追求最大吞吐 echo 0 /sys/block/sda/queue/iosched/low_latency # 关闭设备空转闪存/硬件 RAID 场景 echo 0 /sys/block/sda/queue/iosched/slice_idle # 单位为微秒的等价写法 echo 0 /sys/block/sda/queue/iosched/slice_idle_us # 显式指定最大预算扇区0 表示自动调优 echo 0 /sys/block/sda/queue/iosched/max_budget # 开启严格服务保证注意会强制 slice_idle 8ms echo 1 /sys/block/sda/queue/iosched/strict_guarantees从 block/Kconfig.iosched 的说明可知BFQ 通过 blk-mq 的电梯框架注册iosched_bfq_mq见 block/bfq-iosched.c将 BFQ 设置为活动调度器通常使用echo bfq /sys/block/sda/queue/scheduler5. BFQ 的 cgroup 分组调度BFQ 同时支持 cgroups-v1 和 cgroups-v2 的 io 控制器分别叫blkio与io并提供基于权重的比例共享。要激活 cgroups 支持需在内核配置中设置BFQ_GROUP_IOSCHED见 block/Kconfig.iosched。5.1 提供的服务保证BFQ 下的比例共享意味着真正的设备带宽比例共享按组权重分配。例如权重 200 的组获得的带宽是权重 100 的组的两倍而不仅仅是两倍的时间。BFQ 支持任意深度的层次结构组树。带宽按预期方式在组与进程之间分配对每个组而言其子组按各自权重共享该组的全部带宽。特别地对每个叶子组组内每个进程获得整个组带宽的相同份额除非修改了该进程的 ioprio。组或进程的资源共享保证可能部分或全部从带宽切换到时间当为该组提供带宽保证会导致吞吐下降太多时会发生切换。该切换逐进程进行若叶子组中某进程按带宽份额被服务会导致吞吐损失则 BFQ 只对该进程回退为基于时间的比例共享。5.2 接口与统计文件要让 BFQ 为某设备提供带宽比例共享BFQ 当然必须是该设备的活动调度器。在每个组目录内BFQ 专属的 cgroup 参数与统计文件以bfq.前缀开头。因此 cgroups-v1 的完整前缀是blkio.bfq.、cgroups-v2 是io.bfq.。例如设置组权重的参数是blkio.bfq.weight或io.bfq.weight。cgroups-v1blkio 控制器下的统计文件BFQ 创建并维护的统计文件集合取决于是否设置CONFIG_BFQ_CGROUP_DEBUG若设置CONFIG_BFQ_CGROUP_DEBUGBFQ 创建 Documentation/admin-guide/cgroup-v1/blkio-controller.rst 中记载的全部统计文件若未设置BFQ 只创建以下四个文件blkio.bfq.io_service_bytes blkio.bfq.io_service_bytes_recursive blkio.bfq.io_serviced blkio.bfq.io_serviced_recursive源码中bfq_blkcg_legacy_files[]完整定义了 cgroups-v1 的文件集block/bfq-cgroup.c基础统计为bfq.io_service_bytes读写字节数与bfq.io_serviced读写请求数以及它们的_recursive覆盖组及其后代版本调试统计#ifdef CONFIG_BFQ_CGROUP_DEBUG还包括bfq.time、bfq.sectors、bfq.io_service_time、bfq.io_wait_time、bfq.io_merged、bfq.io_queued及其_recursive版本以及bfq.avg_queue_size、bfq.group_wait_time、bfq.idle_time、bfq.empty_time、bfq.dequeue。cgroups-v2 侧则只暴露bfq.weightbfq_blkg_files[]block/bfq-cgroup.c。CONFIG_BFQ_CGROUP_DEBUG的取值极大地影响 BFQ 可持续的最大吞吐因为更新blkio.bfq.*统计相当昂贵尤其是一些由该选项启用的统计项第 1.1 节的对比数据即为明证。5.3 可设置的参数对每个组可设置以下参数weight该 cgroup 在其父组内部的默认权重可选值1..1000默认100cgroups-v1写入blkio.bfq.weightcgroups-v2写入io.bfq.weight可带可选前缀default加空格第 4.1 节描述的 ioprio 与权重之间的线性映射仍然有效但所有高于IOPRIO_BE_NR * 10的权重都被映射为 ioprio 0再次提醒若low_latency开启BFQ 会自动提升交互式与软实时应用关联队列的权重要自己控制权重请关闭该参数。weight_device为该 cgroup 指定按设备的权重语法minor:major weight写入权重0可重置为默认权重cgroups-v1写入blkio.bfq.weight_devicecgroups-v2文件名为io.bfq.weight。5.4 使用示例# ---- cgroups-v1 ---- # 在 /sys/fs/cgroup/blkio 下为 groupA 设置权重 200 echo 200 /sys/fs/cgroup/blkio/groupA/blkio.bfq.weight # 为特定设备主:次 8:0设置权重 300 echo 8:0 300 /sys/fs/cgroup/blkio/groupA/blkio.bfq.weight_device # 将进程 PID 移入该组 echo $PID /sys/fs/cgroup/blkio/groupA/tasks # 查看 BFQ 基本统计 cat /sys/fs/cgroup/blkio/groupA/blkio.bfq.io_service_bytes cat /sys/fs/cgroup/blkio/groupA/blkio.bfq.io_serviced_recursive # ---- cgroups-v2 ---- # 启用 io 控制器后需先 enable设置默认权重 echo default 200 /sys/fs/cgroup/groupA/io.bfq.weight # 为设备 8:0 设置权重 300io.bfq.weight 即 weight_device 语义 echo 8:0 300 /sys/fs/cgroup/groupA/io.bfq.weight # 将进程移入组cgroups-v2 通过 cgroup.procs / cgroup.threads echo $PID /sys/fs/cgroup/groupA/cgroup.procs6. 典型配置场景速查目标推荐配置代价桌面/交互应用低延迟保持默认low_latency1、slice_idle非零可能牺牲一定吞吐软实时音视频播放/流媒体低丢帧默认基础上开启strict_guarantees1吞吐明显下降最大吞吐闪存/硬件 RAIDlow_latency0、slice_idle0放弃公平性与低延迟强保证机械盘顺序负载高吞吐保持slice_idle开启可增大timeout_sync短期保证粒度变粗显式预算调优max_budgetNN0或增大timeout_sync保持max_budget0需按设备实测多租户带宽隔离启用BFQ_GROUP_IOSCHED按组设置weight/weight_device调度开销随组层次增加7. 进一步阅读与源码入口官方内核文档本文骨架Documentation/block/bfq-iosched.rst核心调度器实现block/bfq-iosched.c约 7678 行含全部 sysfs 参数定义与 store/show 函数调度树算法 B-WF2Qblock/bfq-wf2q.c含bfq_ioprio_to_weight权重映射实现头文件与结构定义block/bfq-iosched.hcgroup 接口实现block/bfq-cgroup.cbfq_blkcg_legacy_files[]与bfq_blkg_files[]内核配置选项block/Kconfig.iosched通用 cgroup-v1 blkio 控制器文档Documentation/admin-guide/cgroup-v1/blkio-controller.rst需要注意的是本文描述的参数默认值与取值范围均以当前内核源码树block/bfq-iosched.c为准slice_idle默认 8ms、可设范围 [0, INT_MAX] msfifo_expire_sync/async默认 125/250ms、最小 1msback_seek_penalty默认 2、最小 1timeout_sync默认 125ms、最小 1mslow_latency与strict_guarantees为布尔量0/1。不同内核版本间默认值可能略有差异实际部署时请以目标内核的 sysfs 输出为准。【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考