Чому Ubuntu 16.04 встановлює всі планувальники вводу-виводу даних на "термін"?

Щойно я встановив 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 .

Чи не було б гарною ідеєю, якби вона була включена? Просто пропозиція!

kernel scheduler

— curt54
джерело

Відповіді:

З випуском 14.04 планувальник за замовчуванням для ядра 3.13 було змінено з CFQ на Deadline .

Більше немає окремого серверного ядра, і графік CFQ не підходить для багатьох сценаріїв використання сервера, наприклад, очікування часу запису KVM . На робочому столі з USB-пристроями є навіть регресії продуктивності .

— НГР
джерело

Дякую за прочитане, дуже просвітлююче! Випуск USB у мене часто був із SD-картами та планшетом майора Android на TWRP. В останньому він би звисав прямо в кінці кілька хвилин. Проблема KVM ніколи не з’являється на моїх гостях VB, оскільки вони знаходяться на моєму SSD без терміну.

— curt54

Команда Ubuntu Kernel регулярно проводить багато аналізу різних модельованих навантажень на різних файлових системах та планувальників вводу / виводу, щоб отримати уявлення про найкращий вибір загального планувальника вводу / виводу. Загальна відповідь полягає в тому, що не існує ідеального вибору планувальника вводу-виводу для загальної конфігурації для всіх установок різних типів для всіх типів носіїв інформації. Важливі моменти, які слід пам'ятати:

Системи переходять на SSD, тому для них найкраще підходить термін або термін; noop має менше центральних витрат, ніж термін.
CFQ vs Deadline - важкий дзвінок. CFQ дозволяє забезпечити більшу гнучкість. Однак ми виявили, що для більш широкого діапазону модельованих операцій вводу / виводу термін передбачав менші затримки і трохи більш високу пропускну здатність, ніж CFQ.
Я регулярно орієнтовую ядра (кожен тест на ядро займає 3+ днів) для різних файлових систем та планувальників вводу-виводу. Виходячи з цього та інших різних даних, ми намагаємось прийняти зважене рішення щодо найкращого вибору, див .:

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

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

— Колін Іан Кінг
джерело

Ми перейшли до використання CFQ в якості замовчування для ядра Ubuntu Zesty 4.10, а також увімкнули нове CONFIG_BLK_WBT_MQ (утилізація багатозаписного зворотного запису), оскільки це вирішує проблеми із запитом брудного кешу на повільних пристроях, таких як флеш-пристрої.

— Колін Іан Кінг

Чи, можливо, ми побачимо BFQ за замовчуванням тепер, коли він знаходиться в ядрі 4.12?

— JauntyDoe

Ми будемо оцінювати це за 4.12 / 4.13, я також зробив кілька ранніх тестувань з kyber, але я перегляну їх ще раз, коли 4.12 вийде на цьому тижні.

— Колін Іан Кінг

В принципі, це питання стосується лише ядра 16.04, але він все ще виникає в пошуку :-). Отож ось нещодавнє оновлення: Ubuntu повернувся до CFQ, що відповідає за замовчуванням у потоці , в Ubuntu 17.04 (цікавий) до 18.10 (космічний) .

— sourcejedi

Подальше оновлення: Linux відключив WBT під час використання CFQ або BFQ (принаймні, за замовчуванням), оскільки він не працює добре разом. 2) Якщо ви хочете оцінити проблему, яку вирішує WBT, я думаю, вам потрібно знати, що проблема залежить від пристроїв (різних прошивок). У ваших результатних показниках я навіть не можу знайти тип пристрою. 3) Мені цікаво ваше опис того, що вирішує WBT. Якщо ви подивитесь супровідний лист на v2 набору патчів WBT, WBT призначений для обробки буферизованих записів на швидкому спалаху, що може мати дуже глибокі черги, і уникати голодування читачів на одному пристрої.

— sourcejedi

Я не знаю, чому розробники вирішили обрати deadlineпланувальник за замовчуванням, можливо, це тому, що більшість нових комп'ютерів постачаються з SSD, на якому зазвичай встановлені системи. Ви можете встановити планувальник вручну таким чином, якщо ви його ще не встановили ... встановіть 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"

Перезавантажте операційну систему, і тепер ви використовуєте оптимальні планувальники для жорстких дисків і SSD.

— cl-netbox
джерело

Так, це я використовував, відповідно до мого оновлення у запитанні. Але я б подумав, що оскільки сьогодні прийнято використовувати обидва типи накопичувачів, це правило було б включено у всі дистрибутиви Linux.

— curt54