1. Зміст статті Не так давно з'явилася інформація, що планувальник BFQ розробники готують до внесення...
2. INFO
3. підготовка
4. Тюнінг планувальників
5. тестування
6. Трохи про процес додавання BFQ в основну гілку ядра
7. Аналіз результатів тестування

Зміст статті

Не так давно з'явилася інформація, що планувальник BFQ розробники готують до внесення в основну гілку ядра. У зв'язку з цим я вирішив зробити огляд планувальників і провести бенчмарки, щоб зрозуміти, в яких ситуаціях вигідніше використовувати той чи інший з них.

Вступ

Для початку згадаємо, що таке планувальник введення / виведення. Він відповідає за розподіл дискових операцій по процесам. У ранніх ядрах Linux (як мінімум в ядрі 2.4) існував тільки один планувальник - Linus Elevator. Він був занадто примітивним, і тому в ядрі 2.6 з'явилися ще три планувальника, частина з яких нині вже пішла в небуття. Таким чином, зараз в ядрі існує три планувальника, а найближчим часом, можливо, додасться ще й четвертий:

• NOOP - найбільш простий планувальник. Він банально поміщає всі запити в чергу FIFO і виконує їх незалежно від того, чи намагаються додатки читати або писати. Планувальник цей, проте, намагається об'єднувати однотипні запити для скорочення операцій введення / виводу.
• CFQ був розроблений в 2003 році. Полягає його алгоритм в наступному. Кожному процесу призначається своя чергу запитів вводу / виводу. Кожній черзі потім присвоюється квант часу. Планувальник ж циклічно обходить всі процеси і обслуговує кожен з них, поки не закінчиться чергу або не закінчиться заданий квант часу. Якщо чергу закінчилася раніше, ніж закінчився виділений для неї квант часу, планувальник почекає (за замовчуванням 10 мс) і, в разі марного очікування, перейде до наступної черги. Зазначу, що в рамках кожної черги читання має пріоритет над записом.
• Deadline в даний час є стандартним планувальником, був розроблений в 2002 році. В основі його роботи, як це зрозуміло з назви, лежить граничний термін виконання - тобто планувальник намагається виконати запит у вказаний час. На додаток до звичайної відсортованої черзі, яка з'явилася ще в Linus Elevator, в ньому є ще дві черги - на читання і на запис. Читання знову ж більш пріоритетно, ніж запис. Крім того, запити об'єднуються в пакети. Пакетом називається послідовність запитів на читання або на запис, яка йде в сторону б? Льшіх секторів ( «алгоритм ліфта»). Після його обробки планувальник дивиться, чи є запити на запис, що не обслуговувалися тривалий час, і в залежності від цього вирішує, чи створювати пакет на читання або ж на запис.
• BFQ (Budget Fair Queueing) - відносно новий планувальник. Базується на CFQ. Якщо не вдаватися в технічні подробиці, кожної черги (яка, як і в CFQ, призначається попроцессного) виділяється свій «бюджет», і, якщо процес інтенсивно працює з диском, даний «бюджет» збільшується.

Але, як то кажуть, не всі грибочки однаково корисні - планувальник для домашнього комп'ютера (який ми і спробуємо вибрати в статті) відрізняється від планувальника для сервера.

INFO

У FreeBSD є фреймворк (GEOM scheduler framework), що дозволяє створювати планувальники введення / виведення. На поточний момент, однак, на ньому базується тільки планувальник rr.

підготовка

Насамперед скачати ядро ​​і накладемо патч BFQ (на момент написання статті існував для ядер по версію 3.13 включно):

$ RELEASE = 3.13.0-v7r2 $ git clone git: //git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux $ cd linux $ git checkout -b stable-3.13 v3.13.7 $ wget -nd --no-parent --level 1 -r -R "* .html *" --reject $ RELEASE http://algo.ing.unimo.it/people/paolo/disk_sched/patches / $ RELEASE $ patch -p1 <./0001-block-cgroups-kconfig-build-bits-for-BFQ-v7r2-3.13.patch $ patch -p1 <./0002-block-introduce-the-BFQ-v7r2- IO-sched-for-3.13.patch $ patch -p1 <./0003-block-bfq-add-Early-Queue-Merge-EQM-to-BFQ-v7r2-for-3.13.0.patch $ cp / boot / config-`uname -r` ./.config

Потім включимо цей планувальник в Enable the block layer -> IO Schedulers (планувальник за замовчуванням можна залишити стандартний - все одно їх можна перемикати як під час роботи, так і використовуючи опції ядра) і скомпілюємо ядро:

$ Fakeroot make-kpkg --initrd --append-to-version = -my kernel_image kernel_headers

Перед цим потрібно переконатися, що у файлі /etc/kernel-pkg.conf варто многопоточная збірка (параметр CONCURRENCY_LEVEL в ідеалі повинен бути дорівнює кількості ядер процесора плюс один).

Включення планувальника BFQ в menuconfig

Слідом же встановлюємо отримані пакети:

$ Sudo dpkg -i ../linux-image-3.13.7-my+_3.13.7-my+-10.00.Custom_amd64.deb ../linux-headers-3.13.7-my+_3.13.7-my+-10.00. Custom_amd64.deb

І перезавантажуємося.

Крім ядра, потрібно встановити деякі пакети для власне бенчмаркінгу:

$ Sudo apt-get install hdparm bonnie ++

Нарешті можна приступати до тестування.

Установка Bonnie ++

Тюнінг планувальників

Як правило, планувальники не вимагають тонкого налаштування. Однак якщо тобі захочеться поекспериментувати - така можливість у нас є. Розглянемо деякі параметри підстроювання BFQ, що знаходяться (в моєму випадку) в каталозі / sys / block / sda / queue / iosched:

• slice_idle - час очікування надходження запитів (в мілісекундах). За замовчуванням 8;
• quantum - число запитів вводу / виводу, переданих дискового контролера за один раз (тим самим обмежуючи довжину черги). Потрібно бути обережними при його збільшенні, оскільки при високому навантаженні система може почати гальмувати. За замовчуванням 4;
• low_latency - для інтерактивних процесів і процесів м'якого реального часу при значенні за замовчуванням намагається дати меншу затримку, ніж для інших процесів. Процеси ці визначаються евристичний;
• max_budget - максимальний бюджет для черги, що вимірюється в секторах. Зрозуміло, цей бюджет застосовується для черги з урахуванням всіх тимчасових лімітів. Значення за замовчуванням дорівнює нулю і включає автоматичне підстроювання даного параметра.

тестування

Перш ніж приступити до проведення бенчмарків, потрібно розповісти про тестовому стенді. Залізо: материнська плата ASUS Sabertooth 990FX R2.0, 16 Гб RAM, Seagate ST3000DM001-1CH166. ПО: Xubuntu 13.10 x64 з ядром 3.13.7. Також в моєму випадку мало сенс створити окремий розділ як мінімум удвічі більшого обсягу, ніж вся доступна оперативна пам'ять, що я і зробив, створивши такий в розмірі 35 Гб з файлової системою ext4. Спочатку переконався, що поточний планувальник для диска - Deadline, для чого наберемо наступну команду:

$ Cat / sys / block / sda / queue / scheduler

Поточний планувальник виділяється квадратними дужками.

Перший бенчмарк, який я проведу, буде тест читання за допомогою утиліти hdparm - хоча призначена вона для тонкого налаштування параметрів HDD, в ній є і бенчмарк.

# Hdparm -tT / dev / sda

Для більш точного результату краще запускати цю команду три - п'ять разів.

Наступним бенчмарком буде тест за допомогою команди dd. Цей тест теж досить корисний для оцінки продуктивності введення / виведення, хоч і здається примітивним.

# Cd / media / rom / benchmarking # time dd if = / dev / zero of =. / Benchfile bs = 1M count = 19900 conv = fdatasync, notrunc

Потім потрібно буде очистити кеш, записавши цифру 3 в файл / proc / sys / vm / drop_caches. Запис цієї цифри в даний файл очищає як сторінковий кеш, так і кеш инод з dentry. Лише після очищення можна буде запустити другу частину тесту:

# Time dd if =. / Benchfile of = / dev / null bs = 1M count = 19900

Як і у випадку з hdparm, обидві частини тесту краще запустити кілька разів.

Переходимо до чергового тесту - їм у нас буде розпакування архіву з ядром. Викачуємо його і запускаємо розпакування (знову ж три - п'ять разів):

# Wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.13.7.tar.xz # time tar xJf linux-3.13.7.tar.xz

Наступний тест буде зроблений за допомогою утиліти Bonnie ++, про яку варто розповісти докладніше. Це вкрай гнучкий набір бенчмарків для тестування продуктивності введення / виведення. Операції з файлами, на жаль, не зводяться тільки до послідовного читання / запису одного файлу або до розпакуванні архіву, тому наведені тести не дають однозначного результату для всіх ситуацій. Bonnie ++ ж, хоч і є синтетичним тестом, більш реалістично симулює звернення до підсистеми введення / виводу. Так, до числа тестів входить симуляція роботи СУБД - в даному випадку створюється файл (або файли, якщо зазначений розмір більший, ніж 1 Гб) і проводиться як послідовне, так і рандомноє читання / запис, при цьому читання в кілька потоків. Крім цього тесту є ще тест на створення / зміна / видалення тисяч маленьких файлів. Опції у цього додатка наступні:

• -d - каталог для роботи програми;
• -s - розмір файлу в мегабайтах для першого тесту (симуляція роботи СУБД). Як я вже сказав, якщо розмір буде вказано більший, ніж 1 Гб, файлів буде більше одного;
• -n - кількість файлів для другого тесту (симуляція роботи Squid або якого-небудь сервера електронної пошти, що використовує для зберігання листів файли). Формат аргументу такий: num: max_size: min_size: num_dirs, де num - кількість файлів, кратне 1024, max_size і min_size - відповідно, максимальний і мінімальний розмір в байтах для створюваних файлів (за умовчанням обидва цих розміру дорівнюють нулю, якщо ж їх встановити, розмір файлів буде задаватися рандомно), а num_dirs - кількість каталогів, в яких файли будуть розміщуватися;
• -x - кількість проходів тестів;
• -q - «тихий» режим. Крім результатів тесту і помилок, нічого не виводиться;
• -u - користувач, під яким запускати тести. Оскільки вони сильно навантажують, користувач root не рекомендується - щоб уникнути усіляких помилок.

Підсумкові команди будуть наступними:

# Mkdir rom && chown rom: rom rom $ bonnie ++ -d ./rom -n 115: 25381: 0: 27 -x 5 -q> ~ / bonnie_out_deadline.csv

Тобто запускаємо п'ять проходів тестів в поточній директорії з кількістю файлів 115 * 1024, максимальним розміром 25 381 байт, кількістю каталогів 27 в «тихому» режимі. Потім потрібно перетворити цей самий CSV в легкий для читання вигляд, для чого в складі пакету є утиліти - можна перетворювати як в txt, так і в HTML:

$ Cat ~ / bonnie_out_deadline.csv | bon_csv2html> ~ / bonnie_out_deadline.html

Нагадаю, що дані тести потрібно проводити на всіх планувальник, а не тільки на поточному. Для їх перемикання є два способи. Перший спосіб - використання параметра завантаження ядра elevator. При цьому потрібно буде редагувати файл / etc / default / grub і оновлювати завантажувальний конфиг GRUB. Другий спосіб не вимагає перезавантаження і полягає у вказівці планувальника через sysfs. Наприклад, для вказівки планувальника CFQ на пристрої / dev / sda досить наступної команди:

# Echo cfq> / sys / block / sda / queue / scheduler

Особисто мені в кінцевому підсумку виявилося простіше написати скрипт, який запускає по п'ять проходів кожного тесту (за винятком Bonnie ++ - в ньому вказується параметр -x) для кожного планувальника. Подивимося ж, що у нас вийшло.

Скрипт для бенчмарка

Трохи про процес додавання BFQ в основну гілку ядра

Я почав роботу над BFQ разом з Фабіо Чекконі (Fabio Checconi) в 2008 році. Фабіо написав першу версію коду. Потім ми протестували його, виправили помилки і трохи поліпшили функціонал. Ми думали, що цього буде достатньо для додавання в ядро:

Однак BFQ не прийняли в основну гілку ядра, незважаючи на позитивний відгук громадськості. Причиною тому послужили зауваження Дженса АКСБ (Jens Axboe). З одного боку, він був стурбований складністю движка планувальника, нарікав на те, що ця складність обернеться проблемами з підтримкою коду, якщо його додадуть в ядро. З іншого - він був переконаний, що в Linux повинен бути тільки один головний планувальник введення / виведення. Їм був (і є) CFQ.

Хоча BFQ не увійшов до ядро, деякі просунуті користувачі стали викачувати його з нашого сайту. BFQ також був включений до деяких модифіковані ядра, наприклад Zen Kernel.

Тим часом я натрапив на одну цікаву гілку LKML по темі введення / виведення. У ній обговорювалося час старту деяких популярних додатків, таких як Firefox і термінал. Я був вражений, наскільки воно може бути мало. По суті, такий час досягалося тільки при послідовному читанні відповідного бінарного файлу. Я надихнувся цією ідеєю і придумав нову фічу для планувальника: необхідно визначати і давати привілеї інтерактивним додатків. Після додавання цього і деяких інших незначних поліпшень я представив BFQ-v1 в липні 2010-го.

З цього моменту BFQ почав набирати обертів: за минулі роки деякі модифіковані Linux-ядра, Android-ядра, дистрибутиви Linux взяли BFQ як планувальника за замовчуванням або додаткового планувальника (pf-kernel, багато ядра для Android, CyanogenMod, Sabayon, Gentoo Linux, Arch Linux, OpenMandriva, Rosa, нині Manjaro). Крім того, за моїми даними, протягом останніх кількох років кожен день планувальник скачують кілька десятків користувачів різних дистрибутивів.

Тим часом я продовжував додавати нові функції та вдосконалення, наприклад евристичні методи розпізнавання інтерактивних додатків. Я додав підтримку нових характеристик жорстких дисків, наприклад NCQ, а також оптимізував роботу з SSD. На щастя, в цій роботі мені допомагали такі хороші люди, як Франческо Аллертс (Francesco Allertsen), Мауро Андреоліні (Mauro Andreolini) і особливо Аріанна Аванціні (Arianna Avanzini). За кілька років вона внесла великий внесок у проект BFQ, розробила нові рішення і підготувала патчі для множин версій ядра.

Всі розширення для правильної обробки нових пристроїв, які Аріанна і я додали в BFQ, були до цього додані і в CFQ. Разом з цим в CFQ з'являлися деякі інші корисні функції. Ми не тільки портіруем всі ці функції в BFQ, але і по можливості допрацьовуємо їх для поліпшення пропускної здатності, часу відгуку і швидкості виконання. Так, нами був розроблений уніфікований механізм обробки введення / виводу QEMU для досягнення високих показників пропускної здатності.

Підтримувати таку високу швидкість розробки зовсім не легко. Без підтримки Аріану проект, швидше за все, довелося б закрити. Однак з виходом версії v7r3 ми врешті-решт зробили це: тепер BFQ підтримує весь спектр популярних пристроїв для зберігання інформації. Крім цього, весь функціонал, який я планував реалізувати, тепер працює стабільно. Нарешті код виглядає зрілим і досить струнким.

Ось чому я думаю, що зараз BFQ готовий для подання в LKML. З цією метою ми вже підготували патчсет для рев'ю. Але, перш ніж приступити до додавання в основну гілку, нам потрібно закінчити тестування версії v7r3 і випустити реліз. Сподіваюся, ми зможемо це зробити в найближчий тиждень.

Паоло Валенте (Paolo Valente), засновник планувальника BFQ

Аналіз результатів тестування

Оскільки написання статті пов'язано з планувальником BFQ, зосередимося саме на ньому.

Запис за допомогою dd у мене зайняла в середньому 137,71 с, що, звичайно, трохи більше, ніж при використанні планувальника Deadline (в середньому 136,89 с), але менше, ніж при використанні інших планувальників, - наприклад, при порівнянні з CFQ BFQ випереджає його майже на 4 с.

Читання ж за допомогою dd настільки значної різниці не показало. Проте в цьому тесті BFQ попереду планети всієї, а CFQ знову аутсайдер.

Тести з допомогою hdparm (читання як з кеша, так і з дискового буфера) з невідомих причин вивели на перше місце планувальник Deadline. Втім, покладатися на результат саме цього тесту особливого сенсу немає - виглядає він надто вже синтетичним.

Замір загального часу виконання розпакування ядра за допомогою команди time знову вивів BFQ на друге місце - хоча і цей тест виглядає не менш синтетичним, ніж попередній.

Таблиця результатів моїх власних тестів

А тепер перейдемо до результатів Bonnie ++. Результатів там багато, але я покажу тільки найосновніші. Розглядати я буду виключно максимальну затримку для однієї операції (знову ж усереднену). При використанні функції putc () затримка у нашого кандидата на включення в ядро ​​становить 12 901 мкс, що виводить його на перше місце. Те ж саме можна сказати і про запис блоку - при даному тесті BFQ виривається далеко вперед. А ось при читанні блоку виграє CFQ з його 9082,6 мкс, BFQ же в цьому тесті (як і в тесті на перезапис блоку) стоїть на другому місці. У тесті послідовного створення файлів BFQ на другому місці, зате в тестах рандомних створення / видалення він знову лідирує.

Таблиця результатів (середнє значення затримки) для Bonnie ++

Як бачимо, в середньому BFQ впевнено займає перше-друге місце. На жаль, у мене немає можливості перевірити SSD-накопичувачі, так що важко сказати, який з планувальників підходить в разі їх використання, але для жорстких дисків BFQ виразно непоганий, так що його можна сміливо включати в якості планувальника за замовчуванням на більшості домашніх комп'ютерів.