选择Linux I / O调度程序
我读到，应该可以通过写入/ sys / block / [disk] / queue / scheduler来更改运行内核上特定设备的I / O调度程序。 例如，我可以在我的系统上看到：
anon@anon:~$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
默认是完全公平的排队调度程序。 我想知道的是，如果在我的定制内核中包含所有四个调度程序有任何用处。 除非内核足够聪明，为正确的硬件选择正确的调度程序，特别是基于闪存的驱动器的“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
理想情况下，会有一个调度程序来满足所有需求。 它似乎还没有存在。 内核通常没有足够的知识为您的工作负载选择最佳的调度程序：
noop通常是内存支持的块设备（例如ramdisk）和其他非旋转介质（闪存）的最佳选择，因为尝试重新计划I / O会浪费资源 deadline是一个轻量级的调度程序，它试图对延迟进行硬限制 cfq试图保持系统级I / O带宽的公平性 默认情况下很长一段时间是anticipatory的，它收到了很多调整，但在2.6.33 （2010年初）被删除。 cfq成为了前些时候的默认选择，因为它的性能合理和公平是多用户系统（甚至单用户桌面）的一个很好的目标。 对于一些场景 - 数据库经常被用作示例，因为它们往往已经有了自己独特的调度和访问模式，并且通常是最重要的服务（所以谁在乎公平性？） - anticipatory存在很长的历史可调性以在这些工作负载上获得最佳性能，并且deadline非常快地将所有请求传递到底层设备。
可以使用udev规则让系统根据hw的某些特性决定调度器。
SSD和其他非旋转式驱动器的示例udev规则可能如下所示
# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", 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运行测试工作负载，测量性能，然后将其作为您的应用的标准工作负载。
在现代的服务器级硬件上，只有noop才显得有用。 其他人在我的测试中看起来更慢。
链接地址: http://www.djcxy.com/p/14841.html