LINUX.ORG.RU

Con Kolivas вернулся: встречайте BFS

 , , ,


0

0

Con Kolivas вернулся с новым планировщиком задач для Линукс ядра BFS (Brain Fuck Scheduler). Цитата:

Почему я написал его?

После многих лет использования моего старого ядра [Линукса] и многочисленных обновлений железа, в конце концов у меня появилось оборудование, которое требовало новых драйверов ядра, а также мне хотелось попробовать новые файловые системы. Загрузка в стандартное ядро [основная ветка на kernel.org] была достаточно обнадёживающей в том, что поведение планировщика стало гораздо лучше, чем в старых ядрах. Однако, много времени не потребовалось, чтобы я разочаровался и в этом [планировщике]. Случайные зависания при движении курсора мыши и нажатиях клавиш, странное распределение процессорного времени при разных вариантах нагрузки на систему и непредсказуемое поведение - это всё то, что, я надеялся, уже исправили. Поэтому я сделал то, чего поклялся никогда не делать - изучил код [планировщика CFS в ядре]. Увидев, что он превратился в монстра невероятных размеров, я сел и поразмыслил, что же в нём не так.

Одна из основных особенностей "справедливости" и интерактивности, за которую я всегда ратовал — это простая семантика того, как должно распределяться процессорное время; с гарантированными низкими задержками так, чтобы интерактивность была гарантирована архитектурой системы, а не так, чтобы она была привинчена с краю [bolted on]. По сути CFS так и делает, но у CFS есть кое-что ещё. CFS варьирует отрезки времени с тем, чтобы попытаться сохранить список завершения задач и определяет распределение процессорного времени, основываясь на отношении работы, поделённой на отдых. CFS также спроектирован, чтобы работать на супер-компьютерах - то, что обычный человек никогда даже не увидит.

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

Поэтому я всё выкинул и начал писать код, работающий приблизительно наоборот.

Что же это такое?

BFS - это аббревиатура от Brain Fuck Scheduler (позволю себе оставить без перевода). Он был разработан по принципу "гляжу только вперёд" и позволяет выжать максимум из достаточно слабых компьютеров, при этом он не ориентирован на суперкомпьютеры. BFS ориентирован на десктоп, имеет при этом по дизайну сверхнизкие задержки для великолепной интерактивности, вместо того, чтобы заниматься подсчётами, при этом BFS имеет настоящую "честность" (распределения процессорного времени), хорошее распределение уровней NICE и отличную масштабируемость при обычных нагрузках.

Отличная масштабируемость при обычных нагрузках? Разве тут нет противоречия?

Многие годы мы нагружали свои Linux системы так, чтобы работы было больше, чем у нас есть процессоров, потому что все мы считали, что jobservers ограничены в своих способностях по полному использованию процессоров (поэтому на 4х процессорном компьютере мы запускали компиляцию в шесть потоков). Мой планировщик доказал, что jobserver ни в чём не виноват, потому что на компьютере с 4 процессорами четыре потока при использовании BFS завершают работу быстрее, чем *любое* количество jobserver'ов при использовании CFS. Предлагаю вам посмотреть на графики обратной масштабируемости Сергея Беляшева, показывающие нагрузку на систему при разном количестве "задач" (jobs) на 4х ядерном компьютере. Планировщик задач в основном ядре никогда не может нагрузить машину полностью - он не может выжать максимум из вашей настольной системы ни при каких обстоятельствах. Отмечу, что этот график достаточно стар - масштабируемость с тех пор улучшилась.

Далее Кон объясняет выбор его имени (потому что, скорее всего, этот планировщик никогда не появится в основном ядре, и BFS не ориентирован на супер-компьютеры, например, на NUMA машины) и даёт рекомендации по его использованию (просто наложите патч на ядро).

>>> BFS Faq

★★★★★

Проверено: boombick ()

а как с realtime приложениями дело обстоит? мне для обработки звука это весьма важно

OzOx
()
Ответ на: комментарий от Relan

> Переключаться между ними в run time нельзя -- только пересобирать ядро.

Под рутом: # echo планировщик > /sys/block/sda/queue/scheduler

Поведение системы меняется, вывод cat /sys/block/sda/queue/scheduler тоже.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

ты тему-то читал? Уже 100 раз писали, чем IO планировщик отличается от сабжа

vovans ★★★★★
()

хм...

linux-2.6.30-tuxonice-r5 # patch -p1 < sched-bfs-203.patch
patching file Documentation/sysctl/kernel.txt
patching file fs/pipe.c
patching file include/linux/init_task.h
patching file include/linux/sched.h
Hunk #9 succeeded at 1595 (offset 1 line).
Hunk #10 succeeded at 2141 (offset 1 line).
patching file kernel/sched.c
Reversed (or previously applied) patch detected! Assume -R? [n]

vovans ★★★★★
()
Ответ на: комментарий от Fragster

>http://www.rhd.ru/docs/articles/schedulers/
прочитал, но так и не понял, что лучше на одноядерной системе.
cfq по идее должен быть самым быстрым, но у меня при копировании система подвисает, как будто в винде дискетку форматируешь :(

Satou ★★★★
()

Конь молодец! Искренне желаю ему успехов.

sabonez ★☆☆☆
()
Ответ на: комментарий от atrus

> В этой теме кто-то массово мешает в одну кучу CFQ, CFS, BFQ и BFS.

Эээ, ну извеняюсь. Просто тормоза IO думаю вызваны именно планировщиком блочных устройств, а не процессов.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

>Эээ, ну извеняюсь. Просто тормоза IO думаю вызваны именно планировщиком блочных устройств, а не процессов.

А тема про тормоза процессов и потоков!!!

Robotron
()
Ответ на: комментарий от vovans

>хм, наложил патч, сделал oldconfig и тишина. В menuconfig тоже ничего не нашёл...

It's designed so that you just patch it in and use it. You shouldn't need to do anything at all.

sky_
()

Где-то 2/3 патча - выкидывание кода, а 1/3 - добавление. Воистину облегченный.

ttnl ★★★★★
()
Ответ на: комментарий от vovans

>ясно. Ну, я так и делаю )) просто пересобираю ядро ))

Отпишись потом, заработало или нет, система загрузилась, как ощущения, какую версию ядра патчил.

Robotron
()
Ответ на: комментарий от vovans

> ясно. Ну, я так и делаю )) просто пересобираю ядро ))

Что-то долго тебя нет, полчаса прошло, мы начинаем волноваться!!

Ядро чтоли полностью перекомпиливаешь?

xintrea
()
Ответ на: комментарий от wolfovich

Та давайте быстрее уже! Народ в нетерпении!

etf
()
Ответ на: комментарий от vovans

ну, занругился.

$ uname -r
2.6.30-tuxonice-r5

вроде всё ок, погонял приложения, игры. ТАк трудно сказать, стало лучше или нет =)

vovans ★★★★★
()
Ответ на: комментарий от vovans

>вроде всё ок, погонял приложения, игры. ТАк трудно сказать, стало лучше или нет =)

Попробуй flash ролики посмотреть отсюда intv.ru к примеру на полный экран и страницу с ними в firefox'е покрутить вверх вниз и отпишись на счёт не стало ли чуть шустрей, ок?

Robotron
()
Ответ на: комментарий от wolfovich

>patch -p1 < filename я ничего не путаю?

Да нет, всё правильно.

P.S. Да, забыл, у меня на эти исходники ещё патчи BFQ были наложены :)

Demon37 ★★★★
()
Ответ на: комментарий от Robotron

Я так понимаю сам автор проводил измерения только на "make -j X"?

madcore ★★★★★
()
Ответ на: комментарий от Reset

>натрави make -j на большой C++ проект, например на boost, а потом попробуй побраузить в ff

Причём укажи у -j число равное количеству ядер твоего проца, если два ядра то 2 и 4/4 соответственно.

Robotron
()
Ответ на: комментарий от Reset

>Нет, у -j указывать ничего не надо. Если будет всё тормозить, то шедулер не помог.

Коливас пишет, что CFQ не может полноценно раздавать ресурсы при количестве заданий равных количеству ядер т.е. по заданию на ядро ввиду своей навороченности. На графике у Коливаса локальный минимум при 4-х заданиях, так же на тачке у него стоит 4-х ядреный проц. Судя по графику нужно ставить у -j число соответствующее именно количеству ядер в системе, не больше не меньше.

Robotron
()
Ответ на: комментарий от Robotron

во время просмотра ролика и операции ниже всё жудко тормозило.. И прокрутка страниц в мозилле дёргалась прилично. Выполнялось ещё вот что:

GOT supertuxkart-0.6.1a.tar.bz2-supertuxkart-0.6.2-src.tar.bz2.dtu

Successfully fetched the dtu-file - let's build supertuxkart-0.6.2-src.tar.bz2...

supertuxkart-0.6.1a.tar.bz2 -> supertuxkart-0.6.2-src.tar.bz2: found bzip2 compressors/decompressors:
/usr/bin/bzip2_1.0.2
/usr/bin/bzip2_1.0.3
using working compression format: 1.0.2

vovans ★★★★★
()
Ответ на: комментарий от Robotron

>Ты много знаешь людей у которых десктоп на NUMA? Кого больше, тех у кого обычный десктоп и они были бы рады большей отзывчивости системы или тех у кого Numa?

У меня десктоп - NUMA. Мне в углу стоять, пока вы радуетесь?

kdf16rc
()
Ответ на: комментарий от vovans

>только вот проц у меня на работе 4-й пень - одноядерный. Компилится игра, тормоза жуткие :(

Дык, тогда у тебя вообще ничего нельзя определить т.к CFS на одноядерном проце выключает практически большую часть логики и работает, как тот простой планировщик на основе которого он сделан. Т.е. основной тормоз CFS, а именно код который решает на каком ядре будет выполнятся поток и какие потоки в какую очередь добавить и т.п. отсутствует. Здесь нужен минимум 2-х ядерный проц.

Robotron
()
Ответ на: комментарий от vovans

> во время просмотра ролика и операции ниже всё жудко тормозило.. И прокрутка страниц в мозилле дёргалась прилично.

В мозилле, кстати, и будет дергаться. У мозиллы на прокрутку/обновление интерфейса навешан какой-то дикий внутренний шедулер, который походу продергивается только если выделен большой кусок процессорного времени. Если много мелких - интерфейс не обновляется.

В Qt с этим получше, если есть возможность, посмотри прогрутку на Opera.

xintrea
()
Ответ на: комментарий от xintrea

>который походу продергивается только если выделен большой кусок процессорного времени. Если много мелких - интерфейс не обновляется.

Почему тогда установка в ядре таймера в 1000hz даёт лучший эффект на прокрутку страницы чем 300hz?

Robotron
()
Ответ на: комментарий от Robotron

Коливасу не нравится, что у него курсор мыши замирает на стандартном шедулере. На BFS у него видимо всё ok. Так вот, то что я описал это стандартный случай когда наблюдается подобный косяк, при этом в венде такого не наблюдается. Поэтому запускать надо именно с -j без параметров иначе смысла нет.

Reset ★★★★★
()
Ответ на: комментарий от Robotron

> Почему тогда установка в ядре таймера в 1000hz даёт лучший эффект на прокрутку страницы чем 300hz?

Понятия не имею. Но факт остается фактом - если запустить архивирование чего-то большого, то работать в фаирфоксе уже нельзя. Прокрутка тормозит, отклик на клики тормозит. В то время как Opera работает нормально, и тормоза видны только если прокручивать (тянуть за движок) длинную страницу вверх-вниз. Тогда видно, что обновляется не мгновенно, а как слайдшоу, правда достаточно быстрое.

xintrea
()

На десктопе максимум времени должно получать активное в данный момент окно. Без интеграции с оконной подсистемой такое в планировщик вкрутить не выйдет.

stellar
()
Ответ на: комментарий от Deleted

> В ядре ЕМНИП даже есть фреймворк для планировщиков

С disk I/O не путайте. Планировщик выполнения процессов в Linux-ядре один -- CFS (не путать с cfq [noop,anticipatory, deadline]), предложение сделать framework, который позволил бы выбирать планировщик, было отвергнуть, и именно это, отчасти, было поводом для Con Kolivas послать всю Лину[к]совую 3,14-здабратию, которая приводила аргументы в духе "какой-нибудь Вася Папкин выберет хреновый планировщик, и его начальники скажут, что Linux -- гов-не-фонтан, и выберут M$" (наличие 3-х планировщиков disk I/O их не смущало -- "политика двойных стандартов" в действии).

poige
()
Ответ на: комментарий от Boy_from_Jungle

> Чем BFQ не устраивает?!

BFQ это disk I/O "elevator"!!!1111!!

$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline cfq [bfq]

poige
()
Ответ на: комментарий от UserUnknown

>У вас часто в рантайме меняется архитектура?

Почему? Горячая замена процессора на сегодня это почти реальность.

Buy ★★★★★
()

> С disk I/O не путайте. Планировщик выполнения процессов в Linux-ядре один -- CFS (не путать с cfq [noop,anticipatory, deadline])

Прочитайте всю тему, я чуть выше написал ровно то же самое. Дважды =)!

> предложение сделать framework, который позволил бы выбирать планировщик, было отвергнуть, и именно это, отчасти, было поводом для Con Kolivas послать всю Лину[к]совую 3,14-здабратию, которая приводила аргументы в духе "какой-нибудь Вася Папкин выберет хреновый планировщик, и его начальники скажут, что Linux -- гов-не-фонтан, и выберут M$" (наличие 3-х планировщиков disk I/O их не смущало -- "политика двойных стандартов" в действии).


Как всё запущено...

Deleted
()

На gentoo-sources-2.6.30-r4 нормально и BFQ и BFS накатились. Вроде все пашет. Насчет быстрее или медленнее не скажу, но явно не хуже. (core2duo T5500)

wolfovich
()
Ответ на: комментарий от TyhDyh

>Собирайте для серверов и суперкомпьютеров ядро с другим планировщиком, чем для десктопов. Ваш КО.

+1 же!

darkshvein ☆☆
()

Интересный момент - фпс в шестерёнках поднялся с 2200-2400 до 2500-2700. Но есть подозрение, что это вызвано ядрёными изменениями(28.15 -30.5).

sky_
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.