Выбор планировщика ввода-вывода Linux

Question

Выбор планировщика ввода-вывода Linux

Я прочитал, что предположительно можно изменить планировщик ввода-вывода для конкретного устройства на работающем ядре, записав в/sys /block/[disk]/queue/scheduler. Например, я могу видеть на моей системе:

anon@anon:~$ cat /sys/block/sda/queue/scheduler 

noop anticipatory deadline [cfq]

что по умолчанию используется полностью честный планировщик очередей. Мне интересно, есть ли какая-либо польза в том числе всех четырех планировщиков в моем пользовательском ядре. Казалось бы, нет большого смысла в том, чтобы иметь более одного планировщика, скомпилированного, если ядро достаточно умен, чтобы выбрать правильный планировщик для правильного оборудования, в частности планировщик "noop" для флэш-накопителей и один из других для традиционного жесткого диска.

это дело?

764 4

linux linux-kernel scheduling

4 ответов:

Comments

Ничего не найдено.

ephemient · Accepted Answer · 2014-06-30 20:29:14

как описано в /usr/src/linux/Documentation/block/switching-sched.txt, планировщик ввода-вывода на любом конкретном блочном устройстве может быть изменен во время выполнения. Может быть некоторая задержка, поскольку все запросы предыдущего планировщика сбрасываются перед использованием нового планировщика, но его можно изменить без проблем, даже когда устройство находится в интенсивном использовании.
# 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 часто является лучшим выбором для устройств с поддержкой памяти (например, ramdisks) и других невращающихся носителей (flash), где попытка перепланировать ввод/вывод является пустой тратой ресурсов

deadline Это легкий планировщик, который пытается поставить жесткий предел задержки

cfq пытается поддерживать общесистемную справедливость пропускной способности ввода/вывода

по умолчанию anticipatory долгое время и он получал много тюнинга, но был удален в 2.6.33 (начало 2010 года). cfq стал дефолтом некоторое время назад, так как его производительность разумна и справедливость является хорошей целью для многопользовательских систем (и даже однопользовательских настольных компьютеров). Для некоторых сценариев -- базы данных часто используются в качестве примеров, поскольку они, как правило, уже имеют свои собственные специфические шаблоны планирования и доступа, и часто являются большинство важное обслуживание (так кто заботится о справедливость?)--anticipatory имеет долгую историю быть настраиваемым для лучшей производительности на этих рабочих нагрузках, и deadline очень быстро передает все запросы к базовому устройству.

Dani_l · Accepted Answer · 2016-02-03 12:20:50

можно использовать правило udev, чтобы система могла принять решение о планировщике на основе некоторых характеристик hw.
Пример правила 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

MarkR · Accepted Answer · 2009-06-18 00:24:42

цель поддержки ядром различных из них заключается в том, что вы можете попробовать их без перезагрузки; затем вы можете запускать тестовые рабочие нагрузки через систему, измерять производительность, а затем сделать это стандартным для вашего приложения.

на современном оборудовании серверного класса только noop one кажется вообще полезным. Другие кажутся медленнее в моих тестах.

KZcoding · Accepted Answer · 2016-02-24 20:31:30

ядро Linux не изменяет автоматически планировщик ввода-вывода во время выполнения. Под этим я подразумеваю, что ядро Linux на сегодняшний день не может автоматически выбирать "оптимальный" планировщик в зависимости от типа вторичного устройства хранения. Во время запуска или во время выполнения можно изменить планировщик ввода-вывода вручную.

планировщик по умолчанию выбирается при запуске на основе содержимого файла, расположенного в /linux-2.6 / block / Kconfig.iosched. Однако можно изменить планировщик ввода-вывода во время выполнения с помощью echoing допустимое имя планировщика в файл, расположенный в /sys/block/[DEV]/queue / scheduler. Например, echo deadline > /sys/block/hda/queue/scheduler