前言
在计算机系统中IO请求分为两种,一种是读请求,一种是写请求,这两种请求对时间的敏感度有很大的差异。进程会因读请求儿进入休眠状态,如果是和用户交互的应用,休眠时间过长会引起明显的卡顿,用户体验便会下降;写请求则不同,它可被系统暂存在IO缓冲区中,等空闲时在将数据写入指定的IO中。
IO调度方式都需要完成请求合并工作,请求的排序工作会因IO器件的不同而有所不同。具体的IO调度方式有以下几种:
linus电梯IO调度方法
这个名字很熟悉,就不多说了。很直观的可以想象IO请求的过程很像乘坐电梯,所以最初Linux系统就使用的是此调度方法。
在此方法中系统只有一个队列用于存放IO请求,当一个新的IO请求准备加入时,会遍历整个队列,查找是否可能合并的请求。如果找到了可以合并的请求,就进行两个请求的合并,这样就可以将两个IO请求变成一个,缩短IO设备的寻址时间;如果没有找到可以合并的IO请求,那么就将此IO请求放在队列的尾部。IO请求插入完成后,会对队列中的请求按照扇区的方向进行排序。
这种调度方法的缺点是没有很好的解决请求的饥饿问题。在极端情况下,有些请求将得到不到执行。另外队列中没有区分读写请求,这样也会加剧读请求延时对系统的影响。
最终期限IO调度方法(deadline)
此调度方法的出现是为了解决电梯调度方法的饥饿问题。在最终期限IO调度方法中,每个请求都有一个超时时间,读请求默认为500ms,写请求默认为5s。方法中需要维护三个队列,分别是排序队列、写