标签：分配   闪存卡   访问   目录   strong   时间   场景   系统   回写   

• 块设备是系统中能够随机（不需要按顺序）访问固定大小数据片的硬件设备，像硬盘
• 字符设备是按照字符流的方式被有序访问，像键盘

IO调度程序

为什么需要IO调度程序：简单的以内核产生请求的次序直接请求的话，磁盘寻址的速度会很慢，性能会很低。IO调度程序会有一定的延迟，对调度队列进行调整

请求队列

一个关于块IO请求的双向链表

Linus电梯（2.4内核，操作系统概念）

• 合并：新请求加入调度队列时，先检查新请求能不能和队列中的请求合并（比如要扫描相邻扇区）；合并失败就插入
• 排序：插入时按磁盘位置排序
• 问题：饥饿现象，一直在相近又刚好是磁盘下一个位置插入新请求

最后期限IO调度程序

除了调度队列外还是用另外四个队列

• 两个排序队列分别包含读写请求，根据磁盘物理位置排序
• 两个最后期限队列分别包含相同的读写请求，根据最后期限排序
• 读请求的超时时间比写请求的超时时间短。因为写是异步的（页回写），不会阻塞；读是同步的，大多会阻塞
• 加入调度队列：
  • 程序交互从两个排序队列头的取出一个请求放入调度队列尾；如果同时调度读写，会选择读
  • 程序还会检查最后期限队列，把超过最后期限的请求放入调度队列尾
• 注意：不保证响应时间，因为检查到超时也只是放入调度队列末尾，但能避免饥饿
• 解决问题：电梯算法的饥饿问题，读优先

预测IO调度程序

最后期限IO调度的一种演变，同样有四个队列，增加了预测启发能力

• 启发预测：
  • 请求提交后不会马上处理下一个请求，而是空闲片刻（默认6-7ms）
  • 原因：因为大多数进程都会连续提交读请求，避免错过后要等待一定时间才能重新提交
• 解决问题：最后期限IO在写操作繁忙时，还是先进行读请求的操作会导致效率不高
• 适合场景：Linux种缺省的IO调度程序

完全公正的排队IO调度程序

• 公平体现在进程级
• 把IO请求放入特定的队列，每个进程有自己的一个队列
• 也会进行合并、排序
• 加入调度队列：轮询方式将各个队列的一组固定数目的请求填充调度队列
• 适合场景：确保磁盘IO带宽的公平分配

空操作的IO调度程序

只合并，基本和FIFO没什么区别

• 适合场景：闪存卡这种真正的随机访问设备，没有寻道的负担

IO调度

标签：分配   闪存卡   访问   目录   strong   时间   场景   系统   回写   

原文地址：https://www.cnblogs.com/wasi-991017/p/14409956.html