Планировщик задач HaikuOS.
BeAR 30 октября, 2009 - 20:58.Предлагаю вашему вниманию пару статей, посвященных планировщику задач HaikuOS.
К сожалению, по техническим причинам опубликовать их на qube.ru не получается (вероятно из–за объёма и обилия тэгов), пока что статьи находятся на другом сайте.
Прямые ссылки:
Планировщик задач HaikuOS. Часть 1. Оцениваем.
Планировщик задач HaikuOS. Часть 2. Переделываем.
Я правильно
Я правильно понимаю, что SOSEmulator в самом последнем эксперименте дал больший time share потоку с приоритетом 100, чем с приоритетом 101? Если да, то назревает кардинальный вопрос: а зачем? :)
Не особо–то
Не особо–то и больше, им досталось примерно поровну. Тоже самое что в Zeta когда все потоки получают хоть сколько–нибудь, самому низкоприоритетному достаётся больше чем тому что чуть более значим.
Просто последний поток нельзя пропускать — очередь закончилась, вот вероятность его выбора от этого и возрастает. Проблему можно обойти дополнительной проверкой с переброской снова в начало очереди.
Улучшил
Улучшил BeOSrt–вариант планировщика:
- и в зоне реального времени, и в зоне разделяемого времени закольцовывается пробег по очереди если она состоит из более чем одной под–очереди
— для под–очереди наименьшего приоритета коэффициент n должен быть всегда меньше или равен таковому для предпоследней очереди
Это вкупе устраняет проблему превышения доли процессорного времени у группы потоков самого низкого приоритета над группой чуть большего.
n для последнего можно было не вычислять а спокойно переиспользовать предыдущее вычисленное, но мне захотелось чтобы всё–таки было различие между тем как высоко от «нуля» подняты последние 2 под–очереди.
Есть пока ещё одна известная мне аномалия распределения процессорного времени которой надо заняться. В логах что приведены в статье её можно наблюдать, странно что я не замечал раньше… Имеет место скачок вероятности, всегда в одном и том же месте для одних и тех же настроек. Но не для любых.
Похоже причина — рандомайзер. Подменой его rand()–ом из stdlib.h скачок устраняется, но rand() тоже не идеален. В общем надо тоже править что есть или придумывать какой–то новый. Единственное «утешение» и «оправдание» — от этой проблемы точно также страдает Zeta 1.51 :)
Улучшенный адд–он BeOSrt носит название BeOSrt2 и добавлен в пакет SOS Emulator'а.
Прочие улучшения:
Вычистил ошибку из запускающего тесты скрипта в пакете SOS Tester'а.
Причесал немного код в целом.
У SOS Emulator'а теперь корректно выгружаются add–on'ы и освобождается память. Мелочь а приятно :)
SOS Emulator делает первые шаги в направлении оценки эффективности планировщика. Размер кванта и дополнительное пенальти на вызов планировщика пока заданы константами и одинаковы для всех add–on'ов.
Обе программы переведены на getopt(), больше вольностей с параметрами сейчас и проще добавлять новые опции в будущем. Исходники дублированы (новый вариант разбора параметров в *2.cpp–файлах) для обратной совместимости, но в следующий раз всё старое пойдёт под нож.
Обновлённые программы расположены по старым адресам:
http://otoko.narod.ru/files/haiku/sos_tester.zip
http://otoko.narod.ru/files/haiku/sos_emulator.zip
Хорошо пишите,
Хорошо пишите, и темы правильные выбираете для экспериментов. С удовольствием почитал бы что–нибудь еще.
прочитал
прочитал с удовольствием, по делу -планировщик Би кмк самый лучший по дефаулту, а настройки планировщика как виртуальной памяти вплоть до реалтайма -идея вообще шикарная
как ее привнести в хайку и офф дерево?
Спасибо. Может
Спасибо. Может быть я эти идеи реализую сам как руки дойдут с мозгами, но вообще–то цель статьи — стукнуть по мозгам тем кто это может сделать гораздо быстрее меня. Правильнее всего возможно было бы написать в список рассылки разработчиков хайку, но сначала хотелось засветить «где попроще», выслушать критику и проч.
Подход к теме
Подход к теме основательный, спасибо, получил удовольствие от прочтения. Думаю, что при такой глубине проработки вопроса говорить о сырости статьи не приходится, разве что ещё раз самому её «с доски» перечитать для верности. :–) Кажется мне, что скоро в haiku–development нам предстоит весьма интересное чтение. ;–)
Планирует
Планирует ли автор все эти результаты и свои наработки предъявить девелоперам гайки?
Ээээ «Спасибо.
Ээээ… «Спасибо. Может быть я эти идеи реализую сам как руки дойдут с мозгами»
Уже.
Уже. Жду реакции. Руки до сырцов гайки у самого пока не дошли.
Axel уже ответил.
Axel уже ответил.
чего сказал?
чего сказал? послал?
В целом да, но я
В целом да, но я сейчас сам встроил что хотел в ядро гайки и гоняю–оцениваю. Разве что настройщика не прикрутил но это пока что не нужно, ядер наплодил — на все случаи жизни :)
Попутно нашёл и полечил проблемки кое–какие с распределением приоритетов системных потоков, теперь не лагает звук в MediaPlayer'е и интерфейс не тормозит если в фоне работают сотни–тысячи потоков B_NORMAL_PRIORITY.
Прочувствовать что проблема была/есть легко — попробуйте послушать музыку в Haiku когда запущено несколько Haiku3d + GLTeapot.
Материала набирается ещё на пару частей статьи…
Сумел решить
Сумел решить какую–то проблему? — делай Commit :)
Вот он мой
Вот он мой коммит:
http://www.freelists.org/post/haiku-development/Scheduler-algorithm–impr…
Пока только так, думаю народ догадается что и где править сам.
Да, уже видел.
Да, уже видел. Хороший пост. Особенно дополнение понравилось :) Про тысячу трёхмерных аппликаций, которых на самом деле восемьсот :)
Дай ядрышко
Дай ядрышко погонять GCC4–ое?
Потерпите
Потерпите чуток. Следующий раз как доберусь до выхода в интернет чего–нибудь выложу. Нетерпеливые могут взять sos_emulator'а и минут за пять конвертировать какой–нибудь из его аддонов в шедулера ядра.
А потом jam kernel
Всётаки,
Всётаки, хотелось бы эти пачи видеть в стандартной Гайке.
Это важно. Давненько подметил в Гайке этакую линуксовую толи виндовую сранную тягу к застываниям, тешила мысль, что мол пре альфа… непойму, чего девелоперы Гайки так уперлись в эти глючные драйвера, проблемы шедулера на лицо, вроде, можно вед тот же драйвер на BeOSе запустить и сравнить.
Он бережет
Он бережет целостность не добавляяя новых сущностей кмк
хотя в данном случае, нужно его убедить хотябы патчи к ядру, проблема со звуком давняя
Там не только
Там не только ядро, много чего шерстить надо.
Спасибо
Спасибо за статью, счас яснее почему BeOS является BeOSью. Надеюсь в Haiku эта сторона будет ещё лучше.
Пробуем
Пробуем экспериментальные планировщики задач Haiku
Предлагаю на распробу результат моих теоретических выкладок и экспериментов, самое вкусное:
http://otoko.narod.ru/files/haiku/haiku_kernel_schedulers.zip
Однопроцессорные варианты гарантированно свободны от глюков. Многопроцессорные варианты мне просто не на чём тестировать, теоретически оно должно работать, но практически — не гарантирую.
Кто есть ху
Haiku–fast
— оптимизированный вариант родного планировщика. Обычному пользователю разницу прочувствовать с родным почти невозможно, но в синтетике ускорение принятия решения по выбору следующего потока в самом сложном случае доходит до 200–кратного, в самом простом случае в 2 раза медленнее родного планировщика.+ в качестве бонуса поправлен баг метода распределения процессорного времени, обычному пользователю тоже вряли получится почувствовать разницу.
BeOS–fast
— оптимизированный вариант а–ля BeOS. Всё тоже самое что и Haiku–fast, только метод распределения процессорного времени как в BeOS (1/(2^n) вместо ~1/4 в Haiku, n — разница между приоритетами).Fair — попытка уйти от проблем планировщиков BeOS/Haiku (потоки меньшего приоритета могли получать процессорного времени больше чем потоки более высокого, отсутствие строгой зависимости для индивидуальных потоков). Метод распределения более хитрый и учитывает количество потоков каждого приоритета. По–умолчанию распределение по формуле 1/(n+1), но доступны и другие варианты (1/(n^2), 1/(2^n), …). Содержит все те же оптимизации что и fast–версии BeOS/Haiku планировщиков, раза в 2–3 их медленнее.
Не будь оптимизаций в сложных случаях честный планировщик был бы до неприличия медлительным, пожирая на моей машине в худшем теоретическом случае до четверти процессорного времени. А так он почти всегда быстрее родного :)
Сделай сам
Т.к. всем не угодишь, кому–то надо GCC2, кому–то — GCC4, да и версии у всех разные (у меня вот r33922), то предлагаю собирать самим, благо всё очень просто.
Сборка ядра с новым планировщиком:
1) Заполучить исходники Haiku.
2) Заменить файл trunk/src/system/kernel/scheduler/scheduler_simple.cpp (однопроцессорный случай) и там же scheduler_affine.cpp (многопроцессорный) на новые по вкусу
У Fair–планировщика перед этим можно выбрать формулу, для этого надо открыть файлы и отредактировать строку
#define SCHED_FORMULA(n) SCHED_FORMULA_N(n)
(вместо макроса-по–умолчанию SCHED_FORMULA_N подставить любой другой из списка).
3) В корне (папка trunk) в Terminal'е сказать: jam configure и затем jam kernel
4) Забрать готовое ядро из trunk/generated/objects/haiku/x86/release/system/kernel
Ложка дёгтя
Следует понимать что планировщик не творит чудес и все глюки обычных приложений никуда не улетучиваются. Как лагал MediaPlayer, так он дальше и будет. Если разработчик программы облажался — все притензии к этому разработчику.
Эффект будет если вычистить баги программ/системных сервисов, устранить все «узкие места». Тогда применение честных планировщиков теоретически должно повысить живучесть и отзывчивость системы в экстремальных ситуациях. Впрочем, какие могут быть экстремальные ситуации на Desktop'е с простенькими приложениями?
За сим откланиваюсь, дальнейшие изыски с планировщиком считаю преждевременными.
PS. Просьба к владельцам многопроцессорных машин — отпишитесь о результате пробы, заработало оно или нет? Для чистоты эксперимента сравните результат со случаем выключенной поддержки многопроцессорности (опция Disable SMP в boot–меню).
PPS. Обновлённый инструментарий естествоиспытателя/изобретателя тут:
http://otoko.narod.ru/files/haiku/sos_tools.zip
2) Заменить файл
2) Заменить файл trunk/src/system/kernel/scheduler/scheduler_simple.cpp (однопроцессорный случай) и там же scheduler_affine.cpp (многопроцессорный) на новые по вкусу
Т. е. для многопроцессорных оба файла заменить нужно? Или же только scheduler_affine.cpp?
Используется
Используется только код из одного файла. Для однопроцессорных машин — simple, многопроцессорных — affine.
Так,
Так, при отключеном SMP работает, при включенном на 2 ядернике интел 7300
такая беда, не грузится гайка, использовались файлы BeOS–fast планировщика
PANIC:ASSERT FAILED (src/system/kernel/sheduler/sheduler_affine/cpp:383):tread==info–>first
Tread 179 “rescan defaults” running on CPU 0
Спасибо
Спасибо за информацию. Примерно понятно в чём дело, попробую решить проблему «в уме» и выложу следующую версию на попробовать.
Полагаю тот же косяк и с другими вариантами планировщика?
Зачем же в уме?
Зачем же в уме? В том же qemu можно выставить любое число ядер и проверить работоспособность.
угу, Haiku -fast
угу, Haiku -fast так же себя ведет..
ща
ща откланиваюсь! на самом интересном месте похериваишь!
ну что за манера, сделать интересное дело и на полпути забить болт..
Галлиум 3Д, планировщик.. не перечесть всего недопиленного, потому Гайка и такая, как засидешееся в девках баба…
ничо не преждевременно, только подумать как динамически изменять параметры, и гуй, пусть в аддонсах лежит готовое, кмк
а Аксель, -это Аксель, не сотвори кумира..
)
И всё–таки
И всё–таки не получается у меня выкинуть шедулера из головы, руки всё–равно тянутся к Haiku :)
Хорошие новости состоят в том что появились новые идеи и кое–что я даже воплотил. Правда пока что код в ядро не перенесён и существует только в эмуляторе. Для переноса в ядро надо само ядро слегка подрихтовать, править Jamfile'ы и возможно что–нибудь ещё. С ходу сделать не получилось, изучаю…
Ну а Axel'ю кое–что понравилось из того что уже накодил. Подготовлю патчи — будет добавлено официально.
спасибо
спасибо огромное.
гайка она такая, не отвяжешься
=)
Исправленые
Исправленые версии по старым адресам. Забирайте.
Отправить комментарий