Почему Ubuntu 16.04 устанавливает для всех планировщиков ввода-вывода привода «крайний срок»?


17

Я только что установил Xubuntu 16.04-64bit на второй раздел на моем ноутбуке. Я заметил, что время от времени это показалось немного медленным, поэтому я проверил, какой планировщик ввода-вывода использовался для этого накопителя, который оказывается deadlineдля всех накопителей. У меня есть пара SSD и жестких дисков, поэтому я знаю, что «крайний срок» лучше всего подходит для SSD и cfqжестких дисков.

Я загрузился в 14.04 на другом разделе, и он использует cfqдля вращающихся дисков и deadlineдля SSD, как и должно. Я также изучил, /etc/udev/rules.dиспользует ли 14.04 правило для настройки типа диска, но его там не было, поэтому я предполагаю, что это делает ядро.

Так что мне интересно, если это ошибка или они используют "срок" для всего сейчас?

Обновление: комментарий, который я написал о /etc/udev/rules.d, был ошибкой. Фактически, я использовал правило udev для изменения планировщика (как и в ответе ниже) в соответствии с типом ротации с тех пор, как я начал использовать SSD несколько лет назад. Я думаю, я просто забыл ... старею. В любом случае, одна из ссылок, которую я использовал, была вики-оптимизация по Debian SSD .

Не было бы хорошей идеей, если бы оно было включено? Просто предложение!

Ответы:


6

С выпуском 14.04 планировщик по умолчанию для ядра 3.13 был изменен с CFQ на Deadline .

Больше нет отдельного серверного ядра, и планировщик CFQ не подходит для многих сценариев использования сервера, например, таймаутов записи KVM . На настольных ПК с USB-устройствами даже наблюдается снижение производительности .


1
Спасибо за прочитанное, очень поучительно! Проблема с USB у меня часто возникала с SD-картами и с майским планшетом Android в TWRP. В последнем он будет висеть прямо в конце на несколько минут. Проблема KVM никогда не отображается на моих гостях VB, так как они на моем SSD с Deadline.
curt54

32

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

  1. Системы переходят на SSD, поэтому для них лучше всего использовать noop или сроки; У noop меньше ресурсов процессора, чем в срок.

  2. CFQ против Deadline - сложный вызов. CFQ позволяет большую гибкость. Однако мы обнаружили, что для более широкого диапазона операций имитации ввода / вывода крайний срок обеспечил меньшие задержки и немного более высокую пропускную способность, чем CFQ.

  3. Я регулярно тестирую ядра (каждый тест ядра занимает более 3 дней) для ряда файловых систем и планировщиков ввода / вывода. Исходя из этой и других различных данных, мы пытаемся принять обоснованное решение о наилучшем выборе, см .:

http://kernel.ubuntu.com/~cking/fs-tests/

У всех планировщиков ввода / вывода есть свои плюсы и минусы, поэтому любое значение по умолчанию не является идеальным, и команда ядра Ubuntu всегда готова внести свой вклад в выбор по умолчанию, если убедительные данные и причины показывают, что мы изменим иначе.


5
Мы перешли к использованию CFQ по умолчанию для ядра Ubuntu Zesty 4.10, а также включили новое CONFIG_BLK_WBT_MQ (регулирование обратной записи в многозадачном режиме), поскольку это решает проблемы обратной записи в грязном кэше на медленных устройствах, таких как флэш-устройства.
Колин Йен Кинг,

1
Возможно, мы увидим BFQ по умолчанию сейчас, когда он находится в ядре 4.12?
JauntyDoe

Мы будем оценивать это для 4.12 / 4.13, я также провел некоторое раннее тестирование с kyber, но я вернусь к ним снова, как только 4.12 выйдет на этой неделе.
Колин Ян Кинг,

В принципе, этот вопрос касается только ядра 16.04, но он все еще встречается в поиске :-). Так вот более последнее обновление: Ubuntu переключился обратно на CFQ, сопрягая вверх по течению по умолчанию в Ubuntu 17.04 (пикантный) через 18.10 (космической) .
sourcejedi

1
Дальнейшее обновление: Linux отключил WBT при использовании CFQ или BFQ (по крайней мере по умолчанию), потому что он не работает хорошо вместе. 2) Если вы хотите оценить проблему, решаемую WBT, я думаю, вам нужно знать, что проблема зависит от устройства (разные прошивки). В ваших результатах теста я даже не могу найти, какой тип устройства использовался. 3) Мне интересно ваше описание того, что разрешает WBT. Если вы посмотрите на сопроводительное письмо на v2 из набора исправлений WBT, WBT разработан для обработки буферизованных записей на быстрой флэш-памяти, которая может иметь очень глубокие очереди и избежать голодания читателей на одном устройстве.
sourcejedi

9

Я не знаю, почему разработчики решили выбрать deadlineпланировщик по умолчанию, возможно, это связано с тем, что большинство новых компьютеров поставляются с твердотельным накопителем, на котором обычно устанавливаются системы. Вы можете установить планировщик вручную таким образом, если вы еще не установили его ... установить gksu:

Откройте терминал и выполните:

sudo apt install gksu  

Затем выполните эту команду:

gksudo gedit /etc/udev/rules.d/60-schedulers.rules  

Вставьте следующий текст в пустой файл и сохраните измененный файл.

# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"  

Перезагрузите операционную систему, и теперь вы используете оптимальные планировщики для жестких дисков и твердотельных накопителей.


Да, это то, что я использовал, согласно моему обновлению в вопросе. Но я думаю, что, поскольку сегодня распространено использование обоих типов дисков, это правило будет включено во все дистрибутивы Linux.
curt54
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.