linuxlowlatency内核

㈠ 技术问题

Code maturity level options
代码成熟度选项

Prompt for development and/or incomplete code/drivers
显示尚在开发中或尚未完成的代码与驱动.除非你是测试人员或者开发者,否则请勿选择

General setup
常规设置

Local version - append to kernel release
在内核版本后面加上自定义的版本字符串(小于64字符),可以用"uname -a"命令看到
Automatically append version information to the version string
自动在版本字符串后面添加版本信息,编译时需要有perl以及git仓库支持
Support for paging of anonymous memory (swap)
使用交换分区或者交换文件来做为虚拟内存
System V IPC
System V进程间通信(IPC)支持,许多程序需要这个功能.必选,除非你知道自己在做什么

IPC Namespaces
IPC命名空间支持,不确定可以不选

POSIX Message Queues
POSIX消息队列,这是POSIX IPC中的一部分
BSD Process Accounting
将进程的统计信息写入文件的用户级系统调用,主要包括进程的创建时间/创建者/内存占用等信息

BSD Process Accounting version 3 file format
使用新的第三版文件格式,可以包含每个进程的PID和其父进程的PID,但是不兼容老版本的文件格式

Export task/process statistics through netlink
通过netlink接口向用户空间导出任务/进程的统计信息,与BSD Process Accounting的不同之处在于这些统计信息在整个任务/进程生存期都是可用的

Enable per-task delay accounting
在统计信息中包含进程等候系统资源(cpu,IO同步,内存交换等)所花费的时间

UTS Namespaces
UTS名字空间支持,不确定可以不选
Auditing support
审计支持,某些内核模块(例如SElinux)需要它,只有同时选择其子项才能对系统调用进行审计

Enable system-call auditing support
支持对系统调用的审计

Kernel .config support
把内核的配置信息编译进内核中,以后可以通过scripts/extract-ikconfig脚本来提取这些信息

Enable access to .config through /proc/config.gz
允许通过/proc/config.gz访问内核的配置信息

Cpuset support
只有含有大量CPU(大于16个)的SMP系统或NUMA(非一致内存访问)系统才需要它
Kernel->user space relay support (formerly relayfs)
在某些文件系统上(比如debugfs)提供从内核空间向用户空间传递大量数据的接口
Initramfs source file(s)
initrd已经被initramfs取代,如果你不明白这是什么意思,请保持空白
Optimize for size (Look out for broken compilers!)
编译时优化内核尺寸(使用"-Os"而不是"-O2"参数编译),有时会产生错误的二进制代码
Enable extended accounting over taskstats
收集额外的进程统计信息并通过taskstats接口发送到用户空间
Configure standard kernel features (for small systems)
配置标准的内核特性(为小型系统)

Enable 16-bit UID system calls
允许对UID系统调用进行过时的16-bit包装
Sysctl syscall support
不需要重启就能修改内核的某些参数和变量,如果你也选择了支持/proc,将能从/proc/sys存取可以影响内核行为的参数或变量
Load all symbols for debugging/kksymoops
装载所有的调试符号表信息,仅供调试时选择

Include all symbols in kallsyms
在kallsyms中包含内核知道的所有符号,内核将会增大300K
Do an extra kallsyms pass
除非你在kallsyms中发现了bug并需要报告这个bug才打开该选项

Support for hot-pluggable devices
支持热插拔设备,如usb与pc卡等,Udev也需要它
Enable support for printk
允许内核向终端打印字符信息,在需要诊断内核为什么不能运行时选择
BUG() support
显示故障和失败条件(BUG和WARN),禁用它将可能导致隐含的错误被忽略
Enable ELF core mps
内存转储支持,可以帮助调试ELF格式的程序
Enable full-sized data structures for core
在内核中使用全尺寸的数据结构.禁用它将使得某些内核的数据结构减小以节约内存,但是将会降低性能
Enable futex support
快速用户空间互斥体可以使线程串行化以避免竞态条件,也提高了响应速度.禁用它将导致内核不能正确的运行基于glibc的程序
Enable eventpoll support
支持事件轮循的系统调用
Use full shmem filesystem
启用shmem支持.shmem是基于共享内存的文件系统(可能用到swap),在启用TMPFS后可以挂载为tmpfs供用户空间使用,它比简单的ramfs先进许多
Use full SLAB allocator
使用SLAB完全取代SLOB进行内存分配,SLAB是一种优秀的内存分配管理器,推荐使用
Enable VM event counters for /proc/vmstat
允许在/proc/vmstat中包含虚拟内存事件记数器

Loadable mole support
可加载模块支持

Enable loadable mole support
打开可加载模块支持,如果打开它则必须通过"make moles_install"把内核模块安装在/lib/moles/中

Mole unloading
允许卸载已经加载的模块

Forced mole unloading
允许强制卸载正在使用中的模块(比较危险)

Mole versioning support
允许使用其他内核版本的模块(可能会出问题)
Source checksum for all moles
为所有的模块校验源码,如果你不是自己编写内核模块就不需要它
Automatic kernel mole loading
让内核通过运行modprobe来自动加载所需要的模块,比如可以自动解决模块的依赖关系

Block layer
块设备层

Enable the block layer
块设备支持,使用硬盘/USB/SCSI设备者必选

Support for Large Block Devices
仅在使用大于2TB的块设备时需要
Support for tracing block io actions
块队列IO跟踪支持,它允许用户查看在一个块设备队列上发生的所有事件,可以通过blktrace程序获得磁盘当前的详细统计数据
Support for Large Single Files
仅在可能使用大于2TB的文件时需要
IO Schelers
IO调度器

Anticipatory I/O scheler
适用于大多数环境,但不太合适数据库应用
Deadline I/O scheler
通常与Anticipatory相当,但更简洁小巧,更适合于数据库应用
CFQ I/O scheler
为所有进程分配等量的带宽,适合于桌面多任务及多媒体应用
Default I/O scheler
默认IO调度器

Processor type and features
中央处理器(CPU)类型及特性

Symmetric multi-processing support
对称多处理器支持,如果你有多个CPU或者使用的是多核CPU就选上.此时"Enhanced Real Time Clock Support"选项必须开启,"Advanced Power Management"选项必须关闭
Subarchitecture Type
处理器的子架构,大多数人都应当选择"PC-compatible"
Processor family
处理器系列,请按照你实际使用的CPU选择
Generic x86 support
通用x86支持,如果你的CPU能够在上述"Processor family"中找到就别选
HPET Timer Support
HPET是替代8254芯片的新一代定时器,i686及以上级别的主板都支持,可以安全的选上
Maximum number of CPUs
支持的最大CPU数,每增加一个内核将增加8K体积
SMT (Hyperthreading) scheler support
支持Intel的超线程(HT)技术
Multi-core scheler support
针对多核CPU进行调度策略优化
Preemption Model
内核抢占模式

No Forced Preemption (Server)
适合服务器环境的禁止内核抢占
Voluntary Kernel Preemption (Desktop)
适合普通桌面环境的自愿内核抢占
Preemptible Kernel (Low-Latency Desktop)
适合运行实时程序的主动内核抢占

Preempt The Big Kernel Lock
可以抢占大内核锁,应用于实时要求高的场合,不适合服务器环境
Machine Check Exception
让CPU检测到系统故障时通知内核,以便内核采取相应的措施(如过热关机等)

Check for non-fatal errors on AMD Athlon/Duron / Intel Pentium 4
每5秒检测一次这些cpu的非致命错误并纠正它们,同时记入日志
check for P4 thermal throttling interrupt
当P4的cpu过热时显示一条警告消息

Enable VM86 support
虚拟X86支持,在DOSEMU下运行16-bit程序或XFree86通过BIOS初始化某些显卡的时候才需要
Toshiba Laptop support
Toshiba笔记本模块支持
Dell laptop support
Dell笔记本模块支持
Enable X86 board specific fixups for reboot
修正某些旧x86主板的重起bug,这种主板基本绝种了
/dev/cpu/microcode - Intel IA32 CPU microcode support
使用不随Linux内核发行的IA32微代码,你必需有IA32微代码二进制文件,仅对Intel的CPU有效
/dev/cpu/*/msr - Model-specific register support
在多cpu系统中让特权CPU访问x86的MSR寄存器
/dev/cpu/*/cpuid - CPU information support
能从/dev/cpu/x/cpuid获得CPU的唯一标识符(CPUID)
Firmware Drivers
固件驱动程序

BIOS Enhanced Disk Drive calls determine boot disk
有些BIOS支持从某块特定的硬盘启动(如果BIOS不支持则可能无法启动),目前大多数BIOS还不支持
BIOS update support for DELL systems via sysfs
仅适用于DELL机器
Dell Systems Management Base Driver
仅适用于DELL机器

High Memory Support
最高内存支持,总内存小于等于1G的选"off",大于4G的选"64G"
Memory split
如果你不是绝对清楚自己在做什么,不要改动这个选项
Memory model
一般选"Flat Memory",其他选项涉及内存热插拔
64 bit Memory and IO resources
使用64位的内存和IO资源
Allocate 3rd-level pagetables from highmem
在内存很多(大于4G)的机器上将用户空间的页表放到高位内存区,以节约宝贵的低端内存
Math emulation
数学协处理器仿真,486DX以上的cpu就不要选它了
MTRR (Memory Type Range Register) support
打开它可以提升PCI/AGP总线上的显卡2倍以上的速度,并且可以修正某些BIOS错误
Boot from EFI support
EFI是一种可代替传统BIOS的技术(目前的Grub/LILO尚不能识别它),但是现在远未普及
Enable kernel irq balancing
让内核将irq中断平均分配给多个CPU以进行负载均衡,但是要配合irqbanlance守护进程才行
Use register arguments
使用"-mregparm=3"参数编译内核,将前3个参数以寄存器方式进行参数调用,可以生成更紧凑和高效的代码
Enable seccomp to safely compute untrusted bytecode
只有嵌入式系统可以不选
Timer frequency
内核时钟频率,桌面推荐"1000 HZ",服务器推荐"100 HZ"或"250 HZ"
kexec system call
提供kexec系统调用,可以不必重启而切换到另一个内核
kernel crash mps
被kexec启动后产生内核崩溃转储
Physical address where the kernel is loaded
内核加载的物理地址,除非你知道自己在做什么,否则不要修改.在提供kexec系统调用的情况下可能要修改它
Support for hot-pluggable CPUs
对热插拔CPU提供支持
Compat VDSO support
如果Glibc版本大于等于2.3.3就不选,否则就选上

更多问题请点这里：http://www.chinaunix.net/jh/4/885597.html

㈡ 如何提高Linux下块设备IO的整体性能

前言：本文主要讲解Linux IO调度层的三种模式：cfp、deadline和noop，并给出各自的优化和适用场景建议。
IO调度发生在Linux内核的IO调度层。这个层次是针对Linux的整体IO层次体系来说的。从read()或者write()系统调用的角度来说，Linux整体IO体系可以分为七层，它们分别是：
VFS层： 虚拟文件系统层。由于内核要跟多种文件系统打交道，而每一种文件系统所实现的数据结构和相关方法都可能不尽相同，所以，内核抽象了这一层，专门用来适配各种文件系统，并对外提供统一操作接口。
文件系统层： 不同的文件系统实现自己的操作过程，提供自己特有的特征，具体不多说了，大家愿意的话自己去看代码即可。
页缓存层： 负责真对page的缓存。
通用块层： 由于绝大多数情况的io操作是跟块设备打交道，所以Linux在此提供了一个类似vfs层的块设备操作抽象层。下层对接各种不同属性的块设备，对上提供统一的Block IO请求标准。
IO调度层 ：因为绝大多数的块设备都是类似磁盘这样的设备，所以有必要根据这类设备的特点以及应用的不同特点来设置一些不同的调度算法和队列。以便在不同的应用环境下有针对性的提高磁盘的读写效率，这里就是大名鼎鼎的Linux电梯所起作用的地方。针对机械硬盘的各种调度方法就是在这实现的。
块设备驱动层： 驱动层对外提供相对比较高级的设备操作接口，往往是C语言的，而下层对接设备本身的操作方法和规范。
块设备层： 这层就是具体的物理设备了，定义了各种真对设备操作方法和规范。
有一个已经整理好的[Linux IO结构图]，非常经典，一图胜千言：

我们今天要研究的内容主要在IO调度这一层。
它要解决的核心问题是，如何提高块设备IO的整体性能？这一层也主要是针对机械硬盘结构而设计的。
众所周知，机械硬盘的存储介质是磁盘，磁头在盘片上移动进行磁道寻址，行为类似播放一张唱片。
这种结构的特点是，顺序访问时吞吐量较高，但是如果一旦对盘片有随机访问，那么大量的时间都会浪费在磁头的移动上，这时候就会导致每次IO的响应时间变长，极大的降低IO的响应速度。
磁头在盘片上寻道的操作，类似电梯调度，实际上在最开始的时期，Linux把这个算法命名为Linux电梯算法，即：
如果在寻道的过程中，能把顺序路过的相关磁道的数据请求都“顺便”处理掉，那么就可以在比较小影响响应速度的前提下，提高整体IO的吞吐量。
这就是我们为什么要设计IO调度算法的原因。
目前在内核中默认开启了三种算法/模式：noop，cfq和deadline。严格算应该是两种：
因为第一种叫做noop，就是空操作调度算法，也就是没有任何调度操作，并不对io请求进行排序，仅仅做适当的io合并的一个fifo队列。
目前内核中默认的调度算法应该是cfq，叫做完全公平队列调度。这个调度算法人如其名，它试图给所有进程提供一个完全公平的IO操作环境。
注：请大家一定记住这个词语，cfq，完全公平队列调度，不然下文就没法看了。
cfq为每个进程创建一个同步IO调度队列，并默认以时间片和请求数限定的方式分配IO资源，以此保证每个进程的IO资源占用是公平的，cfq还实现了针对进程级别的优先级调度，这个我们后面会详细解释。
查看和修改IO调度算法的方法是：

cfq是通用服务器比较好的IO调度算法选择，对桌面用户也是比较好的选择。
但是对于很多IO压力较大的场景就并不是很适应，尤其是IO压力集中在某些进程上的场景。
因为这种场景我们需要更多的满足某个或者某几个进程的IO响应速度，而不是让所有的进程公平的使用IO，比如数据库应用。
deadline调度（最终期限调度）就是更适合上述场景的解决方案。deadline实现了四个队列：
其中两个分别处理正常read和write，按扇区号排序，进行正常io的合并处理以提高吞吐量。因为IO请求可能会集中在某些磁盘位置，这样会导致新来的请求一直被合并，可能会有其他磁盘位置的io请求被饿死。
另外两个处理超时read和write的队列，按请求创建时间排序，如果有超时的请求出现，就放进这两个队列，调度算法保证超时（达到最终期限时间）的队列中的请求会优先被处理，防止请求被饿死。
不久前，内核还是默认标配四种算法，还有一种叫做as的算法（Anticipatory scheler），预测调度算法。一个高大上的名字，搞得我一度认为Linux内核都会算命了。
结果发现，无非是在基于deadline算法做io调度的之前等一小会时间，如果这段时间内有可以合并的io请求到来，就可以合并处理，提高deadline调度的在顺序读写情况下的数据吞吐量。
其实这根本不是啥预测，我觉得不如叫撞大运调度算法，当然这种策略在某些特定场景差效果不错。
但是在大多数场景下，这个调度不仅没有提高吞吐量，还降低了响应速度，所以内核干脆把它从默认配置里删除了。毕竟Linux的宗旨是实用，而我们也就不再这个调度算法上多费口舌了。
1、cfq：完全公平队列调度
cfq是内核默认选择的IO调度队列，它在桌面应用场景以及大多数常见应用场景下都是很好的选择。
如何实现一个所谓的完全公平队列（Completely Fair Queueing）？
首先我们要理解所谓的公平是对谁的公平？从操作系统的角度来说，产生操作行为的主体都是进程，所以这里的公平是针对每个进程而言的，我们要试图让进程可以公平的占用IO资源。
那么如何让进程公平的占用IO资源？我们需要先理解什么是IO资源。当我们衡量一个IO资源的时候，一般喜欢用的是两个单位，一个是数据读写的带宽，另一个是数据读写的IOPS。
带宽就是以时间为单位的读写数据量，比如，100Mbyte/s。而IOPS是以时间为单位的读写次数。在不同的读写情境下，这两个单位的表现可能不一样，但是可以确定的是，两个单位的任何一个达到了性能上限，都会成为IO的瓶颈。
从机械硬盘的结构考虑，如果读写是顺序读写，那么IO的表现是可以通过比较少的IOPS达到较大的带宽，因为可以合并很多IO，也可以通过预读等方式加速数据读取效率。
当IO的表现是偏向于随机读写的时候，那么IOPS就会变得更大，IO的请求的合并可能性下降，当每次io请求数据越少的时候，带宽表现就会越低。
从这里我们可以理解，针对进程的IO资源的主要表现形式有两个： 进程在单位时间内提交的IO请求个数和进程占用IO的带宽。
其实无论哪个，都是跟进程分配的IO处理时间长度紧密相关的。
有时业务可以在较少IOPS的情况下占用较大带宽，另外一些则可能在较大IOPS的情况下占用较少带宽，所以对进程占用IO的时间进行调度才是相对最公平的。
即，我不管你是IOPS高还是带宽占用高，到了时间咱就换下一个进程处理，你爱咋样咋样。
所以，cfq就是试图给所有进程分配等同的块设备使用的时间片，进程在时间片内，可以将产生的IO请求提交给块设备进行处理，时间片结束，进程的请求将排进它自己的队列，等待下次调度的时候进行处理。这就是cfq的基本原理。
当然，现实生活中不可能有真正的“公平”，常见的应用场景下，我们很肯能需要人为的对进程的IO占用进行人为指定优先级，这就像对进程的CPU占用设置优先级的概念一样。
所以，除了针对时间片进行公平队列调度外，cfq还提供了优先级支持。每个进程都可以设置一个IO优先级，cfq会根据这个优先级的设置情况作为调度时的重要参考因素。
优先级首先分成三大类：RT、BE、IDLE，它们分别是实时（Real Time）、最佳效果（Best Try）和闲置（Idle）三个类别，对每个类别的IO，cfq都使用不同的策略进行处理。另外，RT和BE类别中，分别又再划分了8个子优先级实现更细节的QOS需求，而IDLE只有一个子优先级。
另外，我们都知道内核默认对存储的读写都是经过缓存（buffer/cache）的，在这种情况下，cfq是无法区分当前处理的请求是来自哪一个进程的。
只有在进程使用同步方式（sync read或者sync wirte）或者直接IO（Direct IO）方式进行读写的时候，cfq才能区分出IO请求来自哪个进程。
所以，除了针对每个进程实现的IO队列以外，还实现了一个公共的队列用来处理异步请求。
当前内核已经实现了针对IO资源的cgroup资源隔离，所以在以上体系的基础上，cfq也实现了针对cgroup的调度支持。
总的来说，cfq用了一系列的数据结构实现了以上所有复杂功能的支持，大家可以通过源代码看到其相关实现，文件在源代码目录下的block/cfq-iosched.c。
1.1 cfq设计原理
在此，我们对整体数据结构做一个简要描述：首先，cfq通过一个叫做cfq_data的数据结构维护了整个调度器流程。在一个支持了cgroup功能的cfq中，全部进程被分成了若干个contral group进行管理。
每个cgroup在cfq中都有一个cfq_group的结构进行描述，所有的cgroup都被作为一个调度对象放进一个红黑树中，并以vdisktime为key进行排序。
vdisktime这个时间纪录的是当前cgroup所占用的io时间，每次对cgroup进行调度时，总是通过红黑树选择当前vdisktime时间最少的cgroup进行处理，以保证所有cgroups之间的IO资源占用“公平”。
当然我们知道，cgroup是可以对blkio进行资源比例分配的，其作用原理就是，分配比例大的cgroup占用vdisktime时间增长较慢，分配比例小的vdisktime时间增长较快，快慢与分配比例成正比。
这样就做到了不同的cgroup分配的IO比例不一样，并且在cfq的角度看来依然是“公平“的。
选择好了需要处理的cgroup（cfq_group）之后，调度器需要决策选择下一步的service_tree。
service_tree这个数据结构对应的都是一系列的红黑树，主要目的是用来实现请求优先级分类的，就是RT、BE、IDLE的分类。每一个cfq_group都维护了7个service_trees，其定义如下：

其中service_tree_idle就是用来给IDLE类型的请求进行排队用的红黑树。
而上面二维数组，首先第一个维度针对RT和BE分别各实现了一个数组，每一个数组中都维护了三个红黑树，分别对应三种不同子类型的请求，分别是：SYNC、SYNC_NOIDLE以及ASYNC。
我们可以认为SYNC相当于SYNC_IDLE并与SYNC_NOIDLE对应。idling是cfq在设计上为了尽量合并连续的IO请求以达到提高吞吐量的目的而加入的机制，我们可以理解为是一种“空转”等待机制。
空转是指，当一个队列处理一个请求结束后，会在发生调度之前空等一小会时间，如果下一个请求到来，则可以减少磁头寻址，继续处理顺序的IO请求。
为了实现这个功能，cfq在service_tree这层数据结构这实现了SYNC队列，如果请求是同步顺序请求，就入队这个service tree，如果请求是同步随机请求，则入队SYNC_NOIDLE队列，以判断下一个请求是否是顺序请求。
所有的异步写操作请求将入队ASYNC的service tree，并且针对这个队列没有空转等待机制。
此外，cfq还对SSD这样的硬盘有特殊调整，当cfq发现存储设备是一个ssd硬盘这样的队列深度更大的设备时，所有针对单独队列的空转都将不生效，所有的IO请求都将入队SYNC_NOIDLE这个service tree。
每一个service tree都对应了若干个cfq_queue队列，每个cfq_queue队列对应一个进程，这个我们后续再详细说明。
cfq_group还维护了一个在cgroup内部所有进程公用的异步IO请求队列，其结构如下：

异步请求也分成了RT、BE、IDLE这三类进行处理，每一类对应一个cfq_queue进行排队。
BE和RT也实现了优先级的支持，每一个类型有IOPRIO_BE_NR这么多个优先级，这个值定义为8，数组下标为0-7。
我们目前分析的内核代码版本为Linux 4.4，可以看出，从cfq的角度来说，已经可以实现异步IO的cgroup支持了，我们需要定义一下这里所谓异步IO的含义，它仅仅表示从内存的buffer/cache中的数据同步到硬盘的IO请求，而不是aio(man 7 aio)或者linux的native异步io以及lio机制，实际上这些所谓的“异步”IO机制，在内核中都是同步实现的（本质上冯诺伊曼计算机没有真正的“异步”机制）。
我们在上面已经说明过，由于进程正常情况下都是将数据先写入buffer/cache，所以这种异步IO都是统一由cfq_group中的async请求队列处理的。
那么为什么在上面的service_tree中还要实现和一个ASYNC的类型呢？
这当然是为了支持区分进程的异步IO并使之可以“完全公平”做准备喽。
实际上在最新的cgroup v2的blkio体系中，内核已经支持了针对buffer IO的cgroup限速支持，而以上这些可能容易混淆的一堆类型，都是在新的体系下需要用到的类型标记。
新体系的复杂度更高了，功能也更加强大，但是大家先不要着急，正式的cgroup v2体系，在Linux 4.5发布的时候会正式跟大家见面。
我们继续选择service_tree的过程，三种优先级类型的service_tree的选择就是根据类型的优先级来做选择的，RT优先级最高，BE其次，IDLE最低。就是说，RT里有，就会一直处理RT，RT没了再处理BE。
每个service_tree对应一个元素为cfq_queue排队的红黑树，而每个cfq_queue就是内核为进程（线程）创建的请求队列。
每一个cfq_queue都会维护一个rb_key的变量，这个变量实际上就是这个队列的IO服务时间（service time）。
这里还是通过红黑树找到service time时间最短的那个cfq_queue进行服务，以保证“完全公平”。
选择好了cfq_queue之后，就要开始处理这个队列里的IO请求了。这里的调度方式基本跟deadline类似。
cfq_queue会对进入队列的每一个请求进行两次入队，一个放进fifo中，另一个放进按访问扇区顺序作为key的红黑树中。
默认从红黑树中取请求进行处理，当请求的延时时间达到deadline时，就从红黑树中取等待时间最长的进行处理，以保证请求不被饿死。
这就是整个cfq的调度流程，当然其中还有很多细枝末节没有交代，比如合并处理以及顺序处理等等。
1.2 cfq的参数调整
理解整个调度流程有助于我们决策如何调整cfq的相关参数。所有cfq的可调参数都可以在/sys/class/block/sda/queue/iosched/目录下找到，当然，在你的系统上，请将sda替换为相应的磁盘名称。我们来看一下都有什么：

这些参数部分是跟机械硬盘磁头寻道方式有关的，如果其说明你看不懂，请先补充相关知识：
back_seek_max:磁头可以向后寻址的最大范围，默认值为16M。
back_seek_penalty:向后寻址的惩罚系数。这个值是跟向前寻址进行比较的。
以上两个是为了防止磁头寻道发生抖动而导致寻址过慢而设置的。基本思路是这样，一个io请求到来的时候，cfq会根据其寻址位置预估一下其磁头寻道成本。
设置一个最大值back_seek_max，对于请求所访问的扇区号在磁头后方的请求，只要寻址范围没有超过这个值，cfq会像向前寻址的请求一样处理它。
再设置一个评估成本的系数back_seek_penalty，相对于磁头向前寻址，向后寻址的距离为1/2(1/back_seek_penalty)时，cfq认为这两个请求寻址的代价是相同。
这两个参数实际上是cfq判断请求合并处理的条件限制，凡事复合这个条件的请求，都会尽量在本次请求处理的时候一起合并处理。
fifo_expire_async:设置异步请求的超时时间。
同步请求和异步请求是区分不同队列处理的，cfq在调度的时候一般情况都会优先处理同步请求，之后再处理异步请求，除非异步请求符合上述合并处理的条件限制范围内。
当本进程的队列被调度时，cfq会优先检查是否有异步请求超时，就是超过fifo_expire_async参数的限制。如果有，则优先发送一个超时的请求，其余请求仍然按照优先级以及扇区编号大小来处理。
fifo_expire_sync:这个参数跟上面的类似，区别是用来设置同步请求的超时时间。
slice_idle:参数设置了一个等待时间。这让cfq在切换cfq_queue或service tree的时候等待一段时间，目的是提高机械硬盘的吞吐量。
一般情况下，来自同一个cfq_queue或者service tree的IO请求的寻址局部性更好，所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。
当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率，因为固态硬盘没有磁头寻址这个概念，所以在这样的设备上应该设置为0，关闭此功能。
group_idle:这个参数也跟上一个参数类似，区别是当cfq要切换cfq_group的时候会等待一段时间。
在cgroup的场景下，如果我们沿用slice_idle的方式，那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。
这样会如果这个进程一直有请求要处理的话，那么直到这个cgroup的配额被耗尽，同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。
在这种情况下，我们可以将slice_idle ＝ 0而group_idle ＝ 8。这样空转等待就是以cgroup为单位进行的，而不是以cfq_queue的进程为单位进行，以防止上述问题产生。
low_latency:这个是用来开启或关闭cfq的低延时（low latency）模式的开关。
当这个开关打开时，cfq将会根据target_latency的参数设置来对每一个进程的分片时间（slice time）进行重新计算。
这将有利于对吞吐量的公平（默认是对时间片分配的公平）。
关闭这个参数（设置为0）将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的。
我们已经知道cfq设计上有“空转”（idling）这个概念，目的是为了可以让连续的读写操作尽可能多的合并处理，减少磁头的寻址操作以便增大吞吐量。
如果有进程总是很快的进行顺序读写，那么它将因为cfq的空转等待命中率很高而导致其它需要处理IO的进程响应速度下降，如果另一个需要调度的进程不会发出大量顺序IO行为的话，系统中不同进程IO吞吐量的表现就会很不均衡。
就比如，系统内存的cache中有很多脏页要写回时，桌面又要打开一个浏览器进行操作，这时脏页写回的后台行为就很可能会大量命中空转时间，而导致浏览器的小量IO一直等待，让用户感觉浏览器运行响应速度变慢。
这个low_latency主要是对这种情况进行优化的选项，当其打开时，系统会根据target_latency的配置对因为命中空转而大量占用IO吞吐量的进程进行限制，以达到不同进程IO占用的吞吐量的相对均衡。这个开关比较合适在类似桌面应用的场景下打开。
target_latency:当low_latency的值为开启状态时，cfq将根据这个值重新计算每个进程分配的IO时间片长度。
quantum:这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中，超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效。
slice_sync:当一个cfq_queue队列被调度处理时，它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为：time_slice = slice_sync + (slice_sync/5 * (4 - prio))。这个参数对同步请求有效。
slice_async:这个值跟上一个类似，区别是对异步请求有效。
slice_async_rq:这个参数用来限制在一个slice的时间范围内，一个队列最多可以处理的异步请求个数。请求被处理的最大个数还跟相关进程被设置的io优先级有关。
1.3 cfq的IOPS模式
我们已经知道，默认情况下cfq是以时间片方式支持的带优先级的调度来保证IO资源占用的公平。
高优先级的进程将得到更多的时间片长度，而低优先级的进程时间片相对较小。
当我们的存储是一个高速并且支持NCQ（原生指令队列）的设备的时候，我们最好可以让其可以从多个cfq队列中处理多路的请求，以便提升NCQ的利用率。
此时使用时间片的分配方式分配资源就显得不合时宜了，因为基于时间片的分配，同一时刻最多能处理的请求队列只有一个。
这时，我们需要切换cfq的模式为IOPS模式。切换方式很简单，就是将slice_idle=0即可。内核会自动检测你的存储设备是否支持NCQ，如果支持的话cfq会自动切换为IOPS模式。
另外，在默认的基于优先级的时间片方式下，我们可以使用ionice命令来调整进程的IO优先级。进程默认分配的IO优先级是根据进程的nice值计算而来的，计算方法可以在man ionice中看到，这里不再废话。
2、deadline：最终期限调度
deadline调度算法相对cfq要简单很多。其设计目标是：
在保证请求按照设备扇区的顺序进行访问的同时，兼顾其它请求不被饿死，要在一个最终期限前被调度到。
我们知道磁头对磁盘的寻道是可以进行顺序访问和随机访问的，因为寻道延时时间的关系，顺序访问时IO的吞吐量更大，随机访问的吞吐量小。
如果我们想为一个机械硬盘进行吞吐量优化的话，那么就可以让调度器按照尽量复合顺序访问的IO请求进行排序，之后请求以这样的顺序发送给硬盘，就可以使IO的吞吐量更大。
但是这样做也有另一个问题，就是如果此时出现了一个请求，它要访问的磁道离目前磁头所在磁道很远，应用的请求又大量集中在目前磁道附近。
导致大量请求一直会被合并和插队处理，而那个要访问比较远磁道的请求将因为一直不能被调度而饿死。
deadline就是这样一种调度器，能在保证IO最大吞吐量的情况下，尽量使远端请求在一个期限内被调度而不被饿死的调度器。

㈢ 怎样在 Ubuntu 上安装 Linux Kernel 4.4

Android (x86)项目致力于移植Android系统到X86处理器上，使用户可以更容易的在任何电脑上安装Android。他们通过使用android源码，增加补丁来使Android能够在X86处理器，笔记本电脑和平板电脑下工作。
前一段时间，项目组发布了最新的“Android KitKat 4.4 r1”，下面，我将说明如何在VirtualBox上安装。
第一步:在Linux上安装VirtualBox
1、大多数的Linux发行版中，官方源都有VirtualBox，例如在Ubuntu中安装
$ sudo apt-get install virtualbox
第二步:下载并在VirtualBox中安装Android 4.4 kitkat
2、这步挺简单的，只是需要去androud Sourceforge.net项目下载Android 4.4 x86 Kit Kat文件（地址）
3、要想安装Android 4.4 kitkat，首先，你需要启动刚刚下载.iso文件，打开VirtualBox,创建一个新的虚拟机，然后按照下面图片设置：

4、接下来，它会询问你新设备的内存大小，Android 4.4 kikat需要1G内存才能完美运行，但是由于我的电脑只有1G内存，我只能选择512MB。

5、选择“现在创建虚拟硬盘”（“Create a virtual hard drive now”）来创建一个新的硬盘。

6、它现在会询问你新虚拟硬盘的类型，选择VDI

7、现在设置虚拟硬盘大小，你可以按照你的所需来设置任何大小，但是除了将来安装Apps所用的空间，至少需要4G来保证系统正确安装。

8、现在你的新虚拟设备创建好了，可以启动下载的.iso文件了，从左边的列表选择创建的虚拟机，点击设置->存储，如下图，选择android 4.4 kitkat RC2的镜像文件。

9、点击OK,打开机器,启动.iso镜像,选择“安装”开始在虚拟机上安装系统。

10、请选择一个分区来安装Android-x86

11、如下图，你可以看见cfdisk界面，cfdisk是一个分区工具，我们将要使用它来创建一个新的硬盘分区，用来安装Android 4.4，现在，点击“New”

12、选择“Primary”作为分区类型

㈣ 怎么给ubuntu 内核打补丁 成为实时操作系统

linux有实时内核的。
有四种内核，分别为：

-generic
kernel - this is the stock kernel that is provided by
default in Ubuntu.

-preempt
kernel - this kernel is based on the -generic kernel source
tree but is built with different configurations (settings) to rece
latency. Also known as a soft
real-time kernel.

-rt
kernel - is based on the Ubuntu kernel source tree with Ingo
Molnar maintained PREEMPT_RT patch applied to
it. Also known as a hard
real-time kernel.

-lowlatency
kernel - very similar to the -preempt kernel and based on
the -generic kernel source tree, but uses a more aggressive
configuration to further rece latency. Also known as a soft
real-time kernel.

-realtime
kernel - is based on the vanilla kernel source tree with
Ingo
Molnar maintained PREEMPT_RT patch applied to
it. Also known as a hard
real-time kernel.
×*******************************如何选择适合你的内核************************************
Choosing
a Kernel for Your Use Case

These
are some simple guidelines provided to help you understand which
kernel, and in which order, you should test to fit your use case.

If
you do not require low latency for your system then please use the
-generic kernel.

If
you need a low latency system (e.g. for recording audio) then please
use the -preempt kernel as a first choice. This reces latency but
doesn't sacrifice power saving features. It is available only for 64
bit systems (also called amd64).

If
the -preempt kernel does not provide enough low latency for your
needs (or you have an 32 bit system) then you should try the
-lowlatency kernel.

If
the -lowlatency kernel isn't enough then you should try the -rt
kernel

If
the -rt kernel isn't enough stable for you then you should try the
-realtime kernel

××*********************************************去哪里下载内核********************************************8
kernel点ubuntu点com/~kernel-ppa/mainline/

㈤ 如何为Ubuntu升级Linux Kernel 4.4内核

64位系统
wget kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.1-wily/linux-headers-4.4.1-040401_4.4.1-040401.201601311534_all.deb
wget kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.1-wily/linux-headers-4.4.1-040401-generic_4.4.1-040401.201601311534_amd64.deb
wget kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.1-wily/linux-image-4.4.1-040401-generic_4.4.1-040401.201601311534_amd64.deb
32位系统
wget kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.1-wily/linux-headers-4.4.1-040401_4.4.1-040401.201601311534_all.deb
wget kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.1-wily/linux-headers-4.4.1-040401-generic_4.4.1-040401.201601311534_i386.deb
wget kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.1-wily/linux-image-4.4.1-040401-generic_4.4.1-040401.201601311534_i386.deb
下载完成之后请使用如下命令安装 Kernel 4.4.1：
sudo dpkg -i *.deb
安装完成之后使用如下命令更新 Grub boot loader：
sudo update-grub
升级完之后请重启系统。

Ubuntu卸载Linux Kernel 4.4.1
如果你不想用 Linux Kernel 4.4.1 了，可以随时使用如下命令删除：
sudo apt-get remove linux-headers-4.4* linux-image-4.4*
sudo update-grub

㈥ linux进程调度的三种策略是什么

linux内核的三种主要调度策略：
1，SCHED_OTHER 分时调度策略，
2，SCHED_FIFO实时调度策略，先到先服务
3，SCHED_RR实时调度策略，时间片轮转

实时进程将得到优先调用，实时进程根据实时优先级决定调度权值。分时进程则通过nice和counter值决定权值，nice越小，counter越大，被调度的概率越大，也就是曾经使用了cpu最少的进程将会得到优先调度。

SHCED_RR和SCHED_FIFO的不同：
当采用SHCED_RR策略的进程的时间片用完，系统将重新分配时间片，并置于就绪队列尾。放在队列尾保证了所有具有相同优先级的RR任务的调度公平。
SCHED_FIFO一旦占用cpu则一直运行。一直运行直到有更高优先级任务到达或自己放弃。
如果有相同优先级的实时进程（根据优先级计算的调度权值是一样的）已经准备好，FIFO时必须等待该进程主动放弃后才可以运行这个优先级相同的任务。而RR可以让每个任务都执行一段时间。

相同点：
RR和FIFO都只用于实时任务。
创建时优先级大于0(1-99)。
按照可抢占优先级调度算法进行。
就绪态的实时任务立即抢占非实时任务。

所有任务都采用linux分时调度策略时：
1，创建任务指定采用分时调度策略，并指定优先级nice值(-20~19)。
2，将根据每个任务的nice值确定在cpu上的执行时间(counter)。
3，如果没有等待资源，则将该任务加入到就绪队列中。
4，调度程序遍历就绪队列中的任务，通过对每个任务动态优先级的计算权值(counter+20-nice)结果，选择计算结果最大的一个去运行，当这个时间片用完后(counter减至0)或者主动放弃cpu时，该任务将被放在就绪队列末尾(时间片用完)或等待队列(因等待资源而放弃cpu)中。
5，此时调度程序重复上面计算过程，转到第4步。
6，当调度程序发现所有就绪任务计算所得的权值都为不大于0时，重复第2步。

所有任务都采用FIFO时：
1，创建进程时指定采用FIFO，并设置实时优先级rt_priority(1-99)。
2，如果没有等待资源，则将该任务加入到就绪队列中。
3，调度程序遍历就绪队列，根据实时优先级计算调度权值(1000+rt_priority),选择权值最高的任务使用cpu，该FIFO任务将一直占有cpu直到有优先级更高的任务就绪(即使优先级相同也不行)或者主动放弃(等待资源)。
4，调度程序发现有优先级更高的任务到达(高优先级任务可能被中断或定时器任务唤醒，再或被当前运行的任务唤醒，等等)，则调度程序立即在当前任务堆栈中保存当前cpu寄存器的所有数据，重新从高优先级任务的堆栈中加载寄存器数据到cpu，此时高优先级的任务开始运行。重复第3步。
5，如果当前任务因等待资源而主动放弃cpu使用权，则该任务将从就绪队列中删除，加入等待队列，此时重复第3步。

所有任务都采用RR调度策略时：
1，创建任务时指定调度参数为RR，并设置任务的实时优先级和nice值(nice值将会转换为该任务的时间片的长度)。
2，如果没有等待资源，则将该任务加入到就绪队列中。
3，调度程序遍历就绪队列，根据实时优先级计算调度权值(1000+rt_priority),选择权值最高的任务使用cpu。
4，如果就绪队列中的RR任务时间片为0，则会根据nice值设置该任务的时间片，同时将该任务放入就绪队列的末尾。重复步骤3。
5，当前任务由于等待资源而主动退出cpu，则其加入等待队列中。重复步骤3。

系统中既有分时调度，又有时间片轮转调度和先进先出调度：
1，RR调度和FIFO调度的进程属于实时进程，以分时调度的进程是非实时进程。
2，当实时进程准备就绪后，如果当前cpu正在运行非实时进程，则实时进程立即抢占非实时进程。
3，RR进程和FIFO进程都采用实时优先级做为调度的权值标准，RR是FIFO的一个延伸。FIFO时，如果两个进程的优先级一样，则这两个优先级一样的进程具体执行哪一个是由其在队列中的未知决定的，这样导致一些不公正性(优先级是一样的，为什么要让你一直运行?),如果将两个优先级一样的任务的调度策略都设为RR,则保证了这两个任务可以循环执行，保证了公平。

Ingo Molnar-实时补丁
为了能并入主流内核，Ingo Molnar的实时补丁也采用了非常灵活的策略，它支持四种抢占模式：
1．No Forced Preemption (Server)，这种模式等同于没有使能抢占选项的标准内核，主要适用于科学计算等服务器环境。
2．Voluntary Kernel Preemption (Desktop)，这种模式使能了自愿抢占，但仍然失效抢占内核选项，它通过增加抢占点缩减了抢占延迟，因此适用于一些需要较好的响应性的环境，如桌面环境，当然这种好的响应性是以牺牲一些吞吐率为代价的。
3．Preemptible Kernel (Low-Latency Desktop)，这种模式既包含了自愿抢占，又使能了可抢占内核选项，因此有很好的响应延迟，实际上在一定程度上已经达到了软实时性。它主要适用于桌面和一些嵌入式系统，但是吞吐率比模式2更低。
4．Complete Preemption (Real-Time)，这种模式使能了所有实时功能，因此完全能够满足软实时需求，它适用于延迟要求为100微秒或稍低的实时系统。
实现实时是以牺牲系统的吞吐率为代价的，因此实时性越好，系统吞吐率就越低。

㈦ 安装Linux kernel 5.4

下载Linux kernel 5.4的主线包。根据您的操作系统类型，按顺序下载并安装软件包：

• linux-headers-5.4.0-xxxxxx_all.deb

• linux-headers-5.4.0-xxx-generic(/lowlatency)_xxx_amd64.deb

• linux-moles-5.4.0-xxx-generic(/lowlatency)_xxx_amd64.deb

• linux-image-xxx-5.4.0-xxx-generic(/lowlatency)_xxx_amd64.deb

  安装Linux Kernel 5.4
  

㈧ Linux 磁盘IO

磁盘结构与数据存储方式, 数据是如何存储的，又通过怎样的方式被访问？

机械硬盘主要由磁盘盘片、磁头、主轴与传动轴等组成；数据就存放在磁盘盘片中

现代硬盘寻道都是采用CHS( Cylinder Head Sector )的方式，硬盘读取数据时，读写磁头沿径向移动，移到要读取的扇区所在磁道的上方，这段时间称为 寻道时间(seek time) 。 因读写磁头的起始位置与目标位置之间的距离不同，寻道时间也不同 。磁头到达指定磁道后，然后通过盘片的旋转，使得要读取的扇区转到读写磁头的下方，这段时间称为 旋转延迟时间(rotational latencytime) 。然后再读写数据，读写数据也需要时间，这段时间称为 传输时间(transfer time) 。

固态硬盘主要由主控芯片、闪存颗粒与缓存组成；数据就存放在闪存芯片中
通过主控芯片进行寻址， 因为是电信号方式， 没有任何物理结构， 所以寻址速度非常快且与数据存储位置无关

如何查看系统IO状态

查看磁盘空间

调用 open , fwrite 时到底发生了什么?

在一个IO过程中，以下5个API/系统调用是必不可少的
Create 函数用来打开一个文件，如果该文件不存在，那么需要在磁盘上创建该文件
Open 函数用于打开一个指定的文件。如果在 Open 函数中指定 O_CREATE 标记，那么 Open 函数同样可以实现 Create 函数的功能
Clos e函数用于释放文件句柄
Write 和 Read 函数用于实现文件的读写过程

O_SYNC (先写缓存, 但是需要实际落盘之后才返回, 如果接下来有读请求, 可以从内存读 ), write-through
O_DSYNC (D=data, 类似O_SYNC, 但是只同步数据, 不同步元数据)
O_DIRECT (直接写盘, 不经过缓存)
O_ASYNC (异步IO, 使用信号机制实现, 不推荐, 直接用aio_xxx)
O_NOATIME (读取的时候不更新文件 atime(access time))

sync() 全局缓存写回磁盘
fsync() 特定fd的sync()
fdatasync() 只刷数据, 不同步元数据

mount noatime(全局不记录atime), re方式(只读), sync(同步方式)

一个IO的传奇一生 这里有一篇非常好的资料，讲述了整个IO过程；
下面简单记录下自己的理解的一次常见的Linux IO过程， 想了解更详细及相关源码，非常推荐阅读上面的原文

Linux IO体系结构

[站外图片上传中...(image-38a7b-1644137945193)]

Superblock 超级描述了整个文件系统的信息。为了保证可靠性，可以在每个块组中对superblock进行备份。为了避免superblock冗余过多，可以采用稀疏存储的方式，即在若干个块组中对superblock进行保存，而不需要在所有的块组中都进行备份
GDT 组描述符表 组描述符表对整个组内的数据布局进行了描述。例如，数据块位图的起始地址是多少？inode位图的起始地址是多少？inode表的起始地址是多少？块组中还有多少空闲块资源等。组描述符表在superblock的后面
数据块位图 数据块位图描述了块组内数据块的使用情况。如果该数据块已经被某个文件使用，那么位图中的对应位会被置1，否则该位为0
Inode位图 Inode位图描述了块组内inode资源使用情况。如果一个inode资源已经使用，那么对应位会被置1
Inode表 （即inode资源）和数据块。这两块占据了块组内的绝大部分空间，特别是数据块资源

一个文件是由inode进行描述的。一个文件占用的数据块block是通过inode管理起来的 。在inode结构中保存了直接块指针、一级间接块指针、二级间接块指针和三级间接块指针。对于一个小文件，直接可以采用直接块指针实现对文件块的访问；对于一个大文件，需要采用间接块指针实现对文件块的访问

最简单的调度器。它本质上就是一个链表实现的 fifo 队列，并对请求进行简单的 合并 处理。
调度器本身并没有提供任何可以配置的参数

读写请求被分成了两个队列， 一个用访问地址作为索引，一个用进入时间作为索引，并且采用两种方式将这些request管理起来；
在请求处理的过程中，deadline算法会优先处理那些访问地址临近的请求，这样可以最大程度的减少磁盘抖动的可能性。
只有在有些request即将被饿死的时候，或者没有办法进行磁盘顺序化操作的时候，deadline才会放弃地址优先策略，转而处理那些即将被饿死的request

deadline算法可调整参数
read_expire : 读请求的超时时间设置(ms)。当一个读请求入队deadline的时候，其过期时间将被设置为当前时间＋read_expire，并放倒fifo_list中进行排序
write_expire :写请求的超时时间设置(ms)
fifo_batch :在顺序（sort_list）请求进行处理的时候，deadline将以batch为单位进行处理。每一个batch处理的请求个数为这个参数所限制的个数。在一个batch处理的过程中，不会产生是否超时的检查，也就不会产生额外的磁盘寻道时间。这个参数可以用来平衡顺序处理和饥饿时间的矛盾，当饥饿时间需要尽可能的符合预期的时候，我们可以调小这个值，以便尽可能多的检查是否有饥饿产生并及时处理。增大这个值当然也会增大吞吐量，但是会导致处理饥饿请求的延时变长
writes_starved :这个值是在上述deadline出队处理第一步时做检查用的。用来判断当读队列不为空时，写队列的饥饿程度是否足够高，以时deadline放弃读请求的处理而处理写请求。当检查存在有写请求的时候，deadline并不会立即对写请求进行处理，而是给相关数据结构中的starved进行累计，如果这是第一次检查到有写请求进行处理，那么这个计数就为1。如果此时writes_starved值为2，则我们认为此时饥饿程度还不足够高，所以继续处理读请求。只有当starved >= writes_starved的时候，deadline才回去处理写请求。可以认为这个值是用来平衡deadline对读写请求处理优先级状态的，这个值越大，则写请求越被滞后处理，越小，写请求就越可以获得趋近于读请求的优先级
front_merges :当一个新请求进入队列的时候，如果其请求的扇区距离当前扇区很近，那么它就是可以被合并处理的。而这个合并可能有两种情况，一个是向当前位置后合并，另一种是向前合并。在某些场景下，向前合并是不必要的，那么我们就可以通过这个参数关闭向前合并。默认deadline支持向前合并，设置为0关闭

在调度一个request时，首先需要选择一个一个合适的cfq_group。Cfq调度器会为每个cfq_group分配一个时间片，当这个时间片耗尽之后，会选择下一个cfq_group。每个cfq_group都会分配一个vdisktime，并且通过该值采用红黑树对cfq_group进行排序。在调度的过程中，每次都会选择一个vdisktime最小的cfq_group进行处理。
一个cfq_group管理了7棵service tree，每棵service tree管理了需要调度处理的对象cfq_queue。因此，一旦cfq_group被选定之后，需要选择一棵service tree进行处理。这7棵service tree被分成了三大类，分别为RT、BE和IDLE。这三大类service tree的调度是按照优先级展开的

通过优先级可以很容易的选定一类Service tree。当一类service tree被选定之后，采用service time的方式选定一个合适的cfq_queue。每个Service tree是一棵红黑树，这些红黑树是按照service time进行检索的，每个cfq_queue都会维护自己的service time。分析到这里，我们知道，cfq算法通过每个cfq_group的vdisktime值来选定一个cfq_group进行服务，在处理cfq_group的过程通过优先级选择一个最需要服务的service tree。通过该Service tree得到最需要服务的cfq_queue。该过程在 cfq_select_queue 函数中实现

一个cfq_queue被选定之后，后面的过程和deadline算法有点类似。在选择request的时候需要考虑每个request的延迟等待时间，选择那种等待时间最长的request进行处理。但是，考虑到磁盘抖动的问题，cfq在处理的时候也会进行顺序批量处理，即将那些在磁盘上连续的request批量处理掉

cfq调度算法的参数
back_seek_max :磁头可以向后寻址的最大范围，默认值为16M
back_seek_penalty :向后寻址的惩罚系数。这个值是跟向前寻址进行比较的

fifo_expire_async :设置异步请求的超时时间。同步请求和异步请求是区分不同队列处理的，cfq在调度的时候一般情况都会优先处理同步请求，之后再处理异步请求，除非异步请求符合上述合并处理的条件限制范围内。当本进程的队列被调度时，cfq会优先检查是否有异步请求超时，就是超过fifo_expire_async参数的限制。如果有，则优先发送一个超时的请求，其余请求仍然按照优先级以及扇区编号大小来处理
fifo_expire_sync :这个参数跟上面的类似，区别是用来设置同步请求的超时时间
slice_idle :参数设置了一个等待时间。这让cfq在切换cfq_queue或service tree的时候等待一段时间，目的是提高机械硬盘的吞吐量。一般情况下，来自同一个cfq_queue或者service tree的IO请求的寻址局部性更好，所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率，因为固态硬盘没有磁头寻址这个概念，所以在这样的设备上应该设置为0，关闭此功能
group_idle :这个参数也跟上一个参数类似，区别是当cfq要切换cfq_group的时候会等待一段时间。在cgroup的场景下，如果我们沿用slice_idle的方式，那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。这样会如果这个进程一直有请求要处理的话，那么直到这个cgroup的配额被耗尽，同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。在这种情况下，我们可以将slice_idle ＝ 0而group_idle ＝ 8。这样空转等待就是以cgroup为单位进行的，而不是以cfq_queue的进程为单位进行，以防止上述问题产生
low_latency :这个是用来开启或关闭cfq的低延时（low latency）模式的开关。当这个开关打开时，cfq将会根据target_latency的参数设置来对每一个进程的分片时间（slice time）进行重新计算。这将有利于对吞吐量的公平（默认是对时间片分配的公平）。关闭这个参数（设置为0）将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的

target_latency :当low_latency的值为开启状态时，cfq将根据这个值重新计算每个进程分配的IO时间片长度
quantum :这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中，超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效
slice_sync :当一个cfq_queue队列被调度处理时，它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为： time_slice = slice_sync + (slice_sync/5 * (4 - prio)) 这个参数对同步请求有效
slice_async :这个值跟上一个类似，区别是对异步请求有效
slice_async_rq :这个参数用来限制在一个slice的时间范围内，一个队列最多可以处理的异步请求个数。请求被处理的最大个数还跟相关进程被设置的io优先级有关

通常在Linux上使用的IO接口是同步方式的，进程调用 write / read 之后会阻塞陷入到内核态，直到本次IO过程完成之后，才能继续执行，下面介绍的异步IO则没有这种限制，但是当前Linux异步IO尚未成熟

目前Linux aio还处于较不成熟的阶段，只能在 O_DIRECT 方式下才能使用(glibc_aio)，也就是无法使用默认的Page Cache机制

正常情况下，使用aio族接口的简要方式如下：

io_uring 是 2019 年 5 月发布的 Linux 5.1 加入的一个重大特性 —— Linux 下的全新的异步 I/O 支持，希望能彻底解决长期以来 Linux AIO 的各种不足
io_uring 实现异步 I/O 的方式其实是一个生产者-消费者模型:

逻辑卷管理
RAID0
RAID1
RAID5（纠错）
条带化

Linux系统性能调整：IO过程
Linux的IO调度
一个IO的传奇一生
理解inode
Linux 文件系统是怎么工作的？
Linux中Buffer cache性能问题一探究竟
Asynchronous I/O and event notification on linux
AIO 的新归宿：io_uring
Linux 文件 I/O 进化史（四）：io_uring —— 全新的异步 I/O