IO调度
- 块设备是系统中能够随机(不需要按顺序)访问固定大小数据片的硬件设备,像硬盘
- 字符设备是按照字符流的方式被有序访问,像键盘
IO调度程序
为什么需要IO调度程序:简单的以内核产生请求的次序直接请求的话,磁盘寻址的速度会很慢,性能会很低。IO调度程序会有一定的延迟,对调度队列进行调整
请求队列
一个关于块IO请求的双向链表
Linus电梯(2.4内核,操作系统概念)
- 合并:新请求加入调度队列时,先检查新请求能不能和队列中的请求合并(比如要扫描相邻扇区);合并失败就插入
- 排序:插入时按磁盘位置排序
- 问题:饥饿现象,一直在相近又刚好是磁盘下一个位置插入新请求
最后期限IO调度程序
除了调度队列外还是用另外四个队列
- 两个排序队列分别包含读写请求,根据磁盘物理位置排序
- 两个最后期限队列分别包含相同的读写请求,根据最后期限排序
- 读请求的超时时间比写请求的超时时间短。因为写是异步的(页回写),不会阻塞;读是同步的,大多会阻塞
- 加入调度队列:
- 程序交互从两个排序队列头的取出一个请求放入调度队列尾;如果同时调度读写,会选择读
- 程序还会检查最后期限队列,把超过最后期限的请求放入调度队列尾
- 注意:不保证响应时间,因为检查到超时也只是放入调度队列末尾,但能避免饥饿
- 解决问题:电梯算法的饥饿问题,读优先
预测IO调度程序
最后期限IO调度的一种演变,同样有四个队列,增加了预测启发能力
- 启发预测:
- 请求提交后不会马上处理下一个请求,而是空闲片刻(默认6-7ms)
- 原因:因为大多数进程都会连续提交读请求,避免错过后要等待一定时间才能重新提交
- 解决问题:最后期限IO在写操作繁忙时,还是先进行读请求的操作会导致效率不高。启发给予更好的读响应
- 适合场景:Linux中缺省的IO调度程序
完全公正的排队IO调度程序
- 公平体现在进程级
- 把IO请求放入特定的队列,每个进程有自己的一个队列
- 也会进行合并、排序
- 加入调度队列:轮询方式将各个队列的一组固定数目的请求填充调度队列
- 适合场景:确保磁盘IO带宽的公平分配
空操作的IO调度程序
只合并,基本和FIFO没什么区别
- 适合场景:闪存卡这种真正的随机访问设备,没有寻道的负担