Кон Коливас (Con Kolivas) представил (https://lkml.org/lkml/2012/3/24/39) обновлённую версию планировщика задач BFS (http://ck.kolivas.org/patches/bfs/) (Brain Fuck Scheduler), ориентированного на обеспечение оптимальной отзывчивости, интерактивности и пропускной способности при решении типичных пользовательских задач на обычных компьютерах. BFS имеет достаточно простую архитектуру, не усложнённую решением таких задач, как справедливое распределение приоритетов и обеспечение высокой масштабируемости, что обычно не востребовано на пользовательских системах.
Новая версия BFS претерпела достаточно большие архитектурные изменения, необходимые для адаптации работы с ядром 3.3 и не заметные для конечного пользователя. Из изменений, которое может быть замечено пользователями отмечается задействование по умолчанию для x86-систем аккаунтинга IRQ с высоким разрешением, что позволит решить ранее наблюдаемые проблемы с аккаунтингом системного времени.<center><img src="http://www.opennet.me/opennews/pics_base/0_1332690542.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
URL: https://lkml.org/lkml/2012/3/24/39
Новость: http://www.opennet.me/opennews/art.shtml?num=33444
ждём pf 3.3
Народ, там на LMKL есть ссылочка хорошая
TOWARDS TRANSPARENT CPU SCHEDULINGby
Joseph T. MeeheanA dissertation submitted in partial fulfillment of
the requirements for the degree of
Doctor of Philosophy
(Computer Sciences)at the
UNIVERSITY OF WISCONSIN–MADISONhttp://www.cs.wisc.edu/adsl/Publications/meehean-thesis11.pdf
Да и остальные тож интересные - http://research.cs.wisc.edu/adsl/Publications/
---
А по теме, буквально на той неделе ковырял -rt патчи,
гонял на Atom D425 (это 2 ядра на 1.8GHz, по 512Мb L2)
так вот, там latency от 25-38 мкс.---
Скрестить чтоль BFS и RT ?!?!? :D
ну rt для десктопа негоден ни разу, в отличии от
а скрестить...получится хрен знает что
ни рт ни десктоп ни сервак ядро
чушь какая-то
> чушь какая-тоА там новый режим появился - Basic RT (легкий РеалТайм, c ментолом, для девочек).
---В общем, не буду делать, бенчмарки у него жуткие, не попадания в L2 кэш 25% !!!
Подскажи, добрый человек, как ты определял hitrate L2 кэша?
на глаз
мяяяу
Ни я, Mike Galbraith - https://lkml.org/lkml/2012/3/25/38
А рзве цель -rt как раз ни в том, что "между десктоп и rt не должно быть противоречия". Т.е. не запуская rt-процессов, обычные процессы не должны ничего особенного от планировщика почувствовать.
нет, цель РТ давать гарантированные задержки и часто это идёт за счёт существенного падения производительности в общем. Целевая ниша - специальные железки типа там автопилотов.. в ощем, везде где неконтролируемая задержка может привести к негативному результату.
> ждём pf 3.3... без BFS (ибо какой смысл тащить кривые патчи, если они не дают никакого выигрыша?)
ну тебе не дают, а нормальным людям дают, и вполне ощутимый
> ну тебе не дают, а нормальным людям дают, и вполне ощутимыйНормальные люди юзают свежий CFS, который ощутимо шустрее, чем BFS.
ололошеньки
После прочтения сей статьи поставил себе вместе с pf-3.2.5 gentoo-3.3.0. Решил во время компиляции глянуть флеш-видео 360п. При BFS таких лагов просто не было, даже если смотреть в более лучшем качестве.Hardware: core2duo 8400(3ГГц, 2 ядра) и 2 Гб ОЗУ.
дык там помимо сабжа ещё куча изменений.
-ck patchset (BFS), BFQ, TuxOnIce and LinuxIMQ и в частности таймер - в 3.3 до 1000, в пф до 10000, что явно влияет на отзывчивость десктопа.
Ты прав, но я не менял значение в 1000.
> и в частности таймер - в 3.3 до 1000, в пф до 10000,
> что явно влияет на отзывчивость десктопа.Ага щаз, сто тыщь питсот раз...
# grep freq /proc/driver/rtc
periodic IRQ frequency : 1024
max user IRQ frequency : 64
periodic_freq : 1024Частоты, что выше этих значений, "шатает" как
пьяную кобылу с бодуна, +/-5000 us - это нормально.
То, что у вас 10000 это CONFIG_HZ - вакуумный модулятор
таймаутов, задержек и нужен лишь как единый знаменатель
при синхронизациях. И вообще, все продвинутые уже давно юзают NO_HZ.
---
Ядро - это не то место, где надо махать своим органом,
pf-3.2.5, gentoo-3.3.0, bfs, bfq, tux-on-ice, reiser4,
btrfs, wayland, systemd, nosql,... Вау, крошка, да ты крут!!!Понасували говна всякого, уникальные вы мои. :)
А что это тут у нас на графике? Было нечто 64.4 мс, теперь стало 63.9 или 63.6, другими словами примерно на 0,8% или 1,2% меньше. Коливас может и крутой чувак, но не зная что это стало лучше на 1% трудно сказать стоит ли вообще овчинка выделки.
Если производительность повышается даже немного, то явно стоит развиваться в данном направлении.
Производительность как раз уменьшается.
Отзывчивость (вроде как) увеличивается.
Ну и если у вас реакция как терминатора... то да, на 0.1% сможете быстрее выстрелить.
> Производительность как раз уменьшается.Согласно этому графику - увеличивается. Правда на мизер порядка 1%. Что достаточно логично.
>> Производительность как раз уменьшается.
>Согласно этому графику - увеличивается.неа, согласно графику там время, а не мегафлопы. :D
> неа, согласно графику там время, а не мегафлопы. :DСогласно графику, разница пренебрежимо мала, так что пофиг, что там отложено.
И еще подразумеваем, что нам не показывают десятки графиков, где разница отнюдь не в пользу рекламируемого поделия.
> Ну и если у вас реакция как терминатора... то да, на 0.1% сможете быстрее выстрелить.Удачное сравнение.
> сможете быстрее выстрелить.Ну вообще-то если вы не замечаете секунду - вы не терминатор а слоупок. За секунду можно раз 5 пальнуть в кваке.
вообще то там миллисекунды
>Ну вообще-то если вы не замечаете секунду - вы не терминатор а слоупок. За секунду можно раз 5 пальнуть в кваке.странные люди... а вам не всё-равно в кваке, что вы до этого простоите столбом 63 секунды или 64?
зыж
разница составляет менее 1%.
усё.
> разница составляет менее 1%.И это еще лучший результат. Логично предположить, что были и похуже.
> Если производительность повышается даже немного, то явно стоит развиваться в данном направлении.BFS - это не развитие, а деградация. В частности, в нем нет поддержки cgroups, которые, при правильном приготовлении, позволяют добиться значительного увеличения отзывчивости и производительности. В саморекламных "тестах" от Коливаса это, разумеется, пропущено.
Вообще-то предлогалось сделать планировщики заменяемыми(как в дисковой подсистеме). Не думаю, что много кому на десктопе нужны сигрупс(и да, после перехода на системд, который их активно пользует, лучше не стало).
> Вообще-то предлогалось сделать планировщики заменяемыми(как в дисковой подсистеме).
> Не думаю, что много кому на десктопе нужны сигрупс(и да, после
> перехода на системд, который их активно пользует, лучше не стало).Странно. У меня даже после банального включения autogroup все летает просто реактивно, старое ведро с BFS на этом фоне выглядит жутким тормозом.
Не мс, а секунд
А процент тотже.
Во парадокс.
>BFS имеет достаточно простую архитектуруА по названию и не скажешь.
А почему его патчи никак в ядро не примут?
Видимо, название Торвальдсу не нравится ;)
> Видимо, название Торвальдсу не нравится ;)Ему много чего не нравится. KDE SC 4, GNOME 3, Fedora, openSUSE, пароли root.. ))
Должно нравится, он любит дерзкие выражения и даже троллинг.
> Должно нравится, он любит дерзкие выражения и даже троллинг.Зато он не любит индусов и кривой код. Так что по совокупности - не видать Коливасу мейнстрима, как своих ушей.
А все только потому, что появился некий Кон Коливас, чувак с завышенным ЧСВ и давай городить свои велосипеды. Такое не нужно в ядре, кому надо, тот сам вкомпилит.
> некий Кон КоливасПроиграл.
>> некий Кон Коливас
> Проиграл.Крутится рулетка, играет джаз...
Крутится рулетка, играет джаз...
Я проиграл...
Я - Коливас!
>>> некий Кон Коливас
>> Проиграл.
> Крутится рулетка, играет джаз...
> Крутится рулетка, играет джаз...
> Я проиграл...
> Я - Коливас!Там всё гораздо банальнее, они просто с Торвальдсом поцапались
и обозвали друг друга тупыми бакланами,... ну и так далее...
> Там всё гораздо банальнее, они просто с Торвальдсом поцапались
> и обозвали друг друга тупыми бакланами,... ну и так далее...Судя по тому, как работает BFS, прав был таки Торвальдс :)
>> Там всё гораздо банальнее, они просто с Торвальдсом поцапались
>> и обозвали друг друга тупыми бакланами,... ну и так далее...
> Судя по тому, как работает BFS, прав был таки Торвальдс :)Это Вы зря, вещь рабочая, но больше 4-х ядер бестолковая.
Ну а Коливас, как и Рейзер матюгались с ним из-за необходимости
использования функций API ядра, а не писания своих аналогов.
Но ни BFS, ни уж тем более Reiser4 не получаются на чистом Linux API.Вот BTRFS умнее сделали, сначала внедрились в ядро
в кастрированном виде, а теперь херачат чего хотят. :)
>Это Вы зря, вещь рабочая, но больше 4-х ядер бестолковая.да и на моих 4 пршнях тоже бестолковая.
никакой разницы не заметил, зато всякие сигроупс и туева хуча с ними связанная (напрмер фриз - "зафризиваю" браузер к примеру, когда не пользуюсь, чтоб кипятильником ноут не работал) идёт лесом.
>>Это Вы зря, вещь рабочая, но больше 4-х ядер бестолковая.
> да и на моих 4 пршнях тоже бестолковая.Он когда первый патч сделал, везде в анонсах летало, что это ваще
для старых маломощных компов, типа Пень 133МГц. Я вот и не знаю,
нафига он бенчмарки на 16-потоковом Хеон_е делал.Нарыл бы процессоры, какой-нить RDC R8610, STPC Consumer II, иль Geode,
может как Embedded Scheduler прокатит.
> Он когда первый патч сделал, везде в анонсах летало, что это ваще
> для старых маломощных компов, типа Пень 133МГц. Я вот и не знаю,
> нафига он бенчмарки на 16-потоковом Хеон_е делал.Видимо, он с огромным трудом нашел единственный проц, где его поделие хоть чуть-чуть выигрывает, а не сливает.
Я BFS пробовал и на рабочем компе (i5 750), и на домашнем (athlon 2800+) - и там, и там CFS заметно отзывчивее.
Логично. И совпадает с моими наблюдениями.
> Логично. И совпадает с моими наблюдениями.Это был ответ на #36.
> напрмер фриз - "зафризиваю" браузер к примеру, когда не пользуюсь,
> чтоб кипятильником ноут не работалМожно про это подробнее или ссылочку?
> Это Вы зря, вещь рабочая, но больше 4-х ядер бестолковая.Для меня применение понятия "рабочий" к планировщику CPU без cgroups - деление на ноль.
Если cgroups не нужны - ставь фрю или винду, нафига вообще тебе линукс?
> Такое не нужно в ядре, кому надо, тот сам вкомпилит.Не понимаю, кому вообще нужно отрубать себе очень полезные фичи (например, cpu cgroups) без какого-либо выигрыша?
А потому, что он не только уступает CFS по функциональности, но и проигрывает ему на "своем поле": на обычном десктопе CFS из свежих ядер заметно шустрее, чем BFS.
Судя по графику (разница в пределах 1%) и
>>> BFS имеет достаточно простую архитектуру, не усложнённую решением таких задач, как справедливое распределение приоритетов и обеспечение высокой масштабируемостиОно того не стоит. Быть может, как сменяемый планировщик - нормально для желающих экспериментов. Если не ошибаюсь - в ядро вроде бы приняли инфраструктуру для сменяемости планировщиков - так что могут и принять в мейнстрим.
На графике сравнение дается по двойному серверному процесору с 16 потоками, как бы не совсем дексктоп компьютер. А если результаты сравнения привести к реальному рабочему компьютеру один процесор на 2-4 ядра, какой результат будет?
Помню встречал утверждение, что BFS более правильно разделяет нагрузку для процессов с разными приоритетами CFS. Мол CFS почти напроч игнорирует значение nice, а BFS правильно его обрабатывает. Например, если на компьютере в фоне работает несколько неприоритетных процессов, готовых запольнить все процессорное время, то пользователь этого не замичает при использовании BFS и замичает при использовании CFS. Это в самом деле так?
Скорее наоборот, BFS "не усложнен" такой "ненужной на десктопе" фичей, как поддержка приоритетов.
> Это в самом деле так?CFQ default, CGROUPS not set, PREEMPT_NONE=y, NR_CPUS=1, типовой localhost, до 3-х сборок c gcc, фактически загрузка заметна на доке индикатора загрузки.
>... при решении типичных пользовательских задач на обычных компьютерах.Ах...енно, бенчмарки планировщика для хомячков делать на
2-х 8-тредовых Intel Xeon E5620, с суммарными 24 мегами L2 кэша :D
> не усложнённую решением таких задач, как справедливое распределение приоритетов и обеспечение высокой масштабируемости, что обычно не востребовано на пользовательских системахЕсли перевести с маркетингового на русский:
написавший эту поделку индус настолько ленив, что не стал утруждать себя поддержкой киллер-фич, как раз и обеспечивающих высокую отзывчивость CFS.Результат вполне предсказуем: сейчас CFS дает ощутимо более быструю отзывчивость (особенно при правильно приготовленных cgroups), чем BFS. На что рассчитывает Коливас - непонятно.
Там позже отметился Mike Galbraith, это который AUTOGROUP написал,
https://lkml.org/lkml/2012/3/25/38Опустил BFS ниже плинтуса, особо понравилось:
#
What about low latency? A couple latency bound loads:tbench 8
Q6600 desktop box
CFS Throughput 1159.6 MB/sec 8 procs 1.000
BFS Throughput 701.2 MB/sec 8 procs .604 (L2 misses hurt like hell)
