selectLinux I / O调度程序
我读到，应该可以通过写入/ sys / block / [disk] / queue / scheduler来更改正在运行的内核上特定设备的I / O调度程序。 例如，我可以在我的系统上看到：
anon@anon:~$ cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq] 默认是完全公平的排队调度程序。 我想知道的是，如果在我的自定义内核中包含所有四个调度程序有任何用处。 除非内核足够聪明，为正确的硬件select正确的调度程序，特别是基于闪存的驱动器的“noop”调度程序和传统的其他调度程序之一，否则看起来没有太多的关注将多个调度程序编译进去硬盘。
这是这种情况吗？
如/usr/src/linux/Documentation/block/switching-sched.txt ，可以在运行时更改任何特定块设备上的I / O调度程序。 在使用新的调度程序之前，先前调度程序的请求都会被刷新，但可能会有一些延迟，但即使在设备被大量使用的情况下，也可以在没有问题的情况下更改。
# cat /sys/block/hda/queue/scheduler noop deadline [cfq] # echo anticipatory > /sys/block/hda/queue/scheduler # cat /sys/block/hda/queue/scheduler noop [deadline] cfq
理想情况下，将有一个调度程序来满足所有需求。 它似乎还没有存在。 内核往往没有足够的知识来为工作负载select最好的调度器：
-
noop通常是内存支持块设备（例如ramdisk）和其他非旋转介质（闪存）的最佳select，因为尝试重新计划I / O会浪费资源 -
deadline是一个轻量级的调度程序，它试图对延迟进行严格的限制 -
cfq试图保持系统的I / O带宽公平性
默认情况下很长一段时间，并收到了很多调整，但在2.6.33 （2010年初）被删除。 cfq成为了前些时候的默认select，因为它的性能合理和公平是多用户系统（甚至单用户桌面）的一个很好的目标。 对于一些场景 – 数据库往往被用作例子，因为它们往往已经有了自己独特的调度和访问模式，而且往往是最重要的服务（所以谁在乎公平？） – anticipatory存在着很长的历史可调性以在这些工作负载上获得最佳性能，并且deadline将所有请求快速传递到底层设备。
可以使用udev规则让系统根据hw的一些特性决定调度器。
SSD和其他非旋转驱动器的示例udev规则可能如下所示
# set noop scheduler for non-rotating disks ACTION=="add|change", KERNEL=="sd[az]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"
在一个新的udev规则文件（例如/etc/udev/rules.d/60-ssd-scheduler.rules ）中。 这个答案基于debian wiki
要检查ssd磁盘是否使用该规则，可以事先检查触发器属性：
for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done
让内核支持不同的目标是你可以在不重启的情况下尝试它们; 然后您可以通过sytsem运行testing工作负载，衡量性能，然后将其作为您的应用程序的标准工作负载。
在现代服务器级硬件上，只有noop才是有用的。 其他人在我的testing中看起来比较慢。
Linux内核不会在运行时自动更改IO Scheduler。 我的意思是，到目前为止，Linux内核不能根据二级存储设备的types自动select“最优”调度器。 在启动期间或运行期间，可以手动更改IO调度程序。
默认调度程序是在启动时根据/linux-2.6 /block/Kconfig.iosched文件中的内容select的 。 但是，可以在运行时更改IO调度程序，方法是将有效的调度程序名称回送到位于/ sys / block / [DEV] / queue / scheduler的文件中。 例如， echo deadline > /sys/block/hda/queue/scheduler
