如果有个进程正频繁的读写文件，此时你vim查看一个新文件，将会出现明显卡顿。即便你vim查看的文件只有几十M，也可能会出现卡顿。相对的，线上经常遇到IO敏感进程偶发IO超时问题。这些进程一次读写的文件数据量很少，正常几十ms就能搞定，但是超时一次读写文件竟耗时几百ms！为什么会这样？出问题的时间点IO流量很大，磁盘IO使用率util接近100%，磁盘IO带宽占满了，IO压力太大。 原来IO

在上一篇《一次降低进程IO延迟的性能优化实践——基于block层bfq调度器》基础上，本文主要总结实现该IO性能优化过程遇到的 IO卡死、IO重复派发、内核crash等问题。 1：IO重复派发触发了crash 在初版代码编写完成后，启动fio测试+cat读取文件，有很大概率触发了内核crash，现场如下 PID: 11602  TASK: ffff95f3092ddf00  CPU: 3

Linux io调度器有很多种，大多数调度器都经受住了各种市场环境的长时间验证，稳定性、性能得到各种用户的认可，但新的调度器依然展露头角，在4.12内核中出现了一个新的bfq调度器，这个调度器将取代曾经的辉煌的cfq调度器。社区对待大的改动都是很谨慎的，为什么社区最终接受未经市场考验过的bfq调度器呢，本文结合bfq代码对此做个介绍。 一、bfq是什么 bfq全称Budget Fair Que

1 bfq算法基础知识  bfq是cfq的改进版，bfq说明文档bfq-iosched.txt说bfq具有高吞吐、低延迟等特性，适用于互式应用的低延迟场景。在2021年clk还有人专门介绍了Budget Fair Queueing调度算法(bfq)。bfq是怎么做到高吞吐低延迟的？本文基于centos 8.3，内核版本4.18.0-240.el8，探索下bfq算法，详细源码注释见 GitHub

Linux io调度器有很多种，大多数调度器都经受住了各种市场环境的长时间验证，稳定性、性能得到各种用户的认可，但新的调度器依然展露头角，在4.12内核中出现了一个新的bfq调度器，这个调度器将取代曾经的辉煌的cfq调度器。社区对待大的改动都是很谨慎的，为什么社区最终接受未经市场考验过的bfq调度器呢，本文结合bfq代码对此做个介绍。 一、bfq是什么 bfq全称Budget Fair Queu

在前一篇《内核block层IO调度器—bfq算法之1整体流程介绍》文章的基础上，本文主要讲解bfq算法内核源码，建议先看看前一篇文章。本文基于centos 8.3，内核版本4.18.0-240.el8，详细源码注释见 https://github.com/dongzhiyan-stack/linux-4.18.0-240.el8。 相对于deadline算法，bfq算法真的复杂，源码相当繁

在《内核block层IO调度器—bfq算法之2源码详解》文章的基础上，本文主要总结一个bfq算法的源码要点，bfq算法真的复杂！本文基于centos 8.3，内核版本4.18.0-240.el8，详细源码注释见 https://github.com/dongzhiyan-stack/linux-4.18.0-240.el8。 要想了解bfq调度算法的工作原理，我觉得主要还得看派发IO请求的__

本文主要记录bfqq实际调试数据，主要涉及多进程IO传输时bfq调度器如何选择哪个bfqq的entity去使用。在看本文前，建议读者先下之前写的3篇文章《内核block层IO调度器—bfq算法之1整体流程介绍》、《内核block层IO调度器—bfq算法之2源码详解》、《内核block层IO调度器—bfq算法之3源码要点总结》，打个基础。本文基于centos 8.3，内核版本4.18.0-240.

2019独角兽企业重金招聘Python工程师标准>>> 自定义内核显然就是开源的好处之一，不过内核编译属于高级用户（Advanced Users）的范畴，newbies慎入。下面以Fedora 19为例（Fedora 14及更高版本都是通用的内核编译方法，以后如果有变动了我会更新）。 准备工作 终端运行， 1 su-c'yum install rpmdevtoo