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 ()

Что думает общественность о лабораторной работе "реализовать смену планировщика CPU в райнтайме"?

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

> Он просто не видит другой стороны палки: серьёзный рынок серверов и суперкомпьютеров у Linux уже есть, а серьёзного рынка в стороне десктопов ещё нет.

Другой планировщик не отражается на работоспособности userspace приложений. Можно для десктопа включить еще одну rpm'ку с другим ядром.

Проблема в том, чтобы гарантировать стабильность ядра с этими патчами. По этой причине в прошлый раз и был конфликт.

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

> На десктопе максимум времени должно получать активное в данный момент окно. Без интеграции с оконной подсистемой такое в планировщик вкрутить не выйдет.
> stellar * (*) (02.09.2009 16:49:48)

То есть, вы считаете, что всё, что нужно сделать для улучшения отзывчивости системы на десктопах, это научить X-сервер своевременно делать renice? :)

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

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

renice? не надо ничего в ядро.

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

> То есть, вы считаете, что всё, что нужно сделать для улучшения отзывчивости системы на десктопах, это научить X-сервер своевременно делать renice? :)

Ну, как бы было б интересно поработать на системе, в которой X-сервер своевременно делает renice +10 для текущего приложения (окна).

Впринципе, ничего не стоит такое написать (можно и через getpriority()/setpriority(), если ня сях реализовать), вопрос только как определять моменты переключения между окнами, чтоб установить в -10 для покидаемого окна, и +10 для активируемого.

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

+ ещё стоит учитывать оверхед за счёт того, что при переключении нужно производить этот самый renice. Как следствие - в момент переключения как раз и будут наиболее заметные проблемы.

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

а если скомпилить модулем и переключаться на лету?

cetjs
()

Кто-нибудь на SMP машине тесты уже успел прогнать? Как оно?

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

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

Да

> -- только пересобирать ядро.

Нет.

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

Наконец-то кто-то сделал доброе и _действительно_ нужное для линукса.
На фоне Amiga3000, которая с 18 мегами памяти держала 6 графических задач(Real3D, Imagine, LightWave, TVPaint и ещё пару каких-то) и ушла в guru meditation только из-за недостатка памяти, при этом Real и Imagine рейтрейсили) и переключала задачи по одному нажатию Amiga-M, _без_ всяких перерисовок, без мерцающих окон, без лагов, прямо в момент нажатия моментально показывала нужное приложение - на фоне всего этого современные компьютеры с монстроподобными оболочками и чудовищными обьёмами памяти выглядят как....как даже не знаю как назвать, бл..дство какое-то.

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

Javelin
()

Эй, плеерописатели! И IM-клиентописатели вместе с ними. Не чуете, что хреновней занимаетесь, не?

oguretz
()

Небольшой прирост есть, SBU на 5 секунд уменьшилось, но при второй загрузке все зависло.

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

>вот и будут у линукса несколько планировщиков - для десктопов , для супер-компьютеров , для домохозяек , кто там еще ?

Помнится, их было три. Потом допилили CFS, который все равно был хуже для десктопа, чем планировщик в 2.4.

И сделали разные ключики для разного поведения.

Но вообще логично - для проверки серверных возможностей на десктопе хватит и десктопного планировщика. А к серверу поставить другое ядро и не париться.

Вон на винде 2003 и XP ядра разнятся.

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

> О, подскажи где нашёл компьютерный стол для HP Superdome?

HP xw9400

$ numastat
node0 node1
numa_hit 54491847 12392032
numa_miss 3446807 5579196
numa_foreign 5579196 3446807
interleave_hit 4810 4725
local_node 54399000 12122627
other_node 3539654 5848601

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

>Помнится, их было три. Потом допилили CFS, который все равно был хуже для десктопа, чем планировщик в 2.4.

О, да, планировщики из 2.4 это вообще тихий ужас был. Сейчас хоть какая отзывчивость есть. Планировщики из 2.4 не были заточены на десктоп вообще.

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

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

Да я думаю на глаз это заметно не будет :(

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

> Впринципе, ничего не стоит такое написать (можно и через getpriority()/setpriority(), если ня сях реализовать), вопрос только как определять моменты переключения между окнами, чтоб установить в -10 для покидаемого окна, и +10 для активируемого.

Чот до меня не дошло почему так, а не наоборот?!

Boy_from_Jungle ★★★★
()

Лайнус еще не комментировал это в своем стиле, типа "опять этот сраный тупой мудак приперся"?

Слово правильно пишется scheduler.

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

>-10 для покидаемого окна, и +10 для активируемого.

Да, наоборот и ниже нуля только для рута

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

>То есть, вы считаете, что всё, что нужно сделать для улучшения отзывчивости системы на десктопах, это научить X-сервер своевременно делать renice? :)

Только через renice эту задачу не решить.

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

> вопрос только как определять моменты переключения между окнами, чтоб установить в -10 для покидаемого окна, и +10 для активируемого.

Окна? Приоритеты назначаются процессам, а не окнам. Похоже на ЛОР начало проникать ВГМ...

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

>О, да, планировщики из 2.4 это вообще тихий ужас был. Сейчас хоть какая отзывчивость есть. Планировщики из 2.4 не были заточены на десктоп вообще.

Ну хз. Мышь у меня ни разу на 2.4 не висла и музыка не заикалась, если проблемы были.

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

> Окна? Приоритеты назначаются процессам, а не окнам.

А что, в системе нет информации об окне и связанных с ним процессах?

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

>А что, в системе нет информации об окне и связанных с ним процессах?

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

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

>На фоне Amiga3000

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

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

>О, да, планировщики из 2.4 это вообще тихий ужас был. Сейчас хоть какая отзывчивость есть. Планировщики из 2.4 не были заточены на десктоп вообще.

Не вижу никакой видимой разницы. Более того, имхо во времена ядер 2.4 УИ на десктопах тупил не в пример меньше, чем сейчас.

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

>> А что, в системе нет информации об окне и связанных с ним процессах?

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


Значит, ты продолжаешь щитать, что в системе нет информации об окне и связанных с ним процессах?

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

>> О, да, планировщики из 2.4 это вообще тихий ужас был. Сейчас хоть какая отзывчивость есть. Планировщики из 2.4 не были заточены на десктоп вообще.

> Не вижу никакой видимой разницы. Более того, имхо во времена ядер 2.4 УИ на десктопах тупил не в пример меньше, чем сейчас.


Согласен, на 2.4 все просто летает на том же железе. Может быть, дело в том, что программы со временем становятся больше и тормознее?

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

>Не вижу никакой видимой разницы. Более того, имхо во времена ядер 2.4 УИ на десктопах тупил не в пример меньше, чем сейчас

Во времена 2.4 в ядре единственной блокировкой было BKL (big kernel lock), что стопорило всю систему. Это было вынужденное решение и сейчас от этого уходят. В ядрах 2.6.30 и 2.6.31 много уже в этом плане сделано, см.чейнжлог ядер. То, что тупит десктоп в наши времена это вина окружения ядра (gnome, kde, xserver). Само ядро гораздо шустрее сейчас и отзывчевее, что во времена 2.4, пропускная способность дисковой системы тоже на высоте относительно 2.4

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

Во времена 2.4 в ядре единственной блокировкой было BKL (big kernel lock), что стопорило всю систему. Это было вынужденное решение и сейчас от этого уходят. В ядрах 2.6.30 и 2.6.31 много уже в этом плане сделано, см.чейнжлог ядер. То, что тупит десктоп в наши времена это вина окружения ядра (gnome, kde, xserver). Само ядро гораздо шустрее сейчас и отзывчевее, ЧЕМ во времена 2.4. Пропускная способность дисковой системы в ядре 2.6 (особенно 2.6.3x) тоже на высоте относительно 2.4

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

> Само ядро гораздо шустрее сейчас и отзывчевее,

ну да
всегда есть на кого спихнуть

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

> было б интересно поработать на системе, в которой X-сервер своевременно делает renice +10 для текущего приложения (окна).

Интересно, какому процессу (PID) надо менять приоритет, если я переключился в окно XTerm? А если этот XTerm был запущен командой { ssh -X user@remoteserver xterm ; } ???

no-dashi ★★★★★
()

Чем SCHED_ULE v.3 не устраивает? (Ниразу не видел замёрзший курсор мыши и AAC не заикается при воспроизведении при 100% загрузке CPU другими процессами). Его лицензия позволяет воровать код гнутикам.

iZEN ★★★★★
()
Ответ на: комментарий от no-dashi

> Интересно, какому процессу (PID) надо менять приоритет, если я переключился в окно XTerm?

Очевидно, PID, соответствующий xterm.


> А если этот XTerm был запущен командой { ssh -X user@remoteserver xterm ; } ???


Смотря про что идет речь. Если про сервер, то ничего не менять, мы же говорим о локальном десктопе. Если про клиент, то PID, соответствующий ssh.

xintrea
()

Собрал с 2.6.30.5 ничего не изменилось. Даже flash на весь экран тормозит как раньше, хотя сколько было разговоров в сети про этот flash.

По мне, так лучше без всяких факовых планировщиков, и вообще очень жду 2.6.31

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

gentoo x64 2.6.30-r4.

без BSF сборка gcc-4.3.2-r3 (emerge), j5:

real 33m55.679s user 48m12.953s sys 12m40.124s

с BSF, те же условия, j2: real 32m54.936s user 48m10.533s sys 13m1.441s

прирост незначителен. замеры проводились при загрузки без всего (Interactive mode, skip all, ctrl+D, root password, emerge)

Гуй ведет себя так же.

core 2 duo 7250

С BSF sshfs намертво вешает машину.

вывод: фпечь.

PS: у друзей на одноголовых машинах вроде как гуй нереально ускорился.

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