Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пн дек 18, 2017 12:36 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 22 сообщения ]  На страницу 1 2 След.
Автор Сообщение
 Заголовок сообщения: Приоритеты в планировщике задач
СообщениеДобавлено: Пн май 27, 2013 12:52 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
В r3534 я закоммитила реализацию приоритетов для планировщика.
* Одно большое кольцо потоков разбивается на NR_SCHED_QUEUES колец поменьше.
* Нулевое кольцо содержит потоки ядра, включая основной и USB. Последнее кольцо содержит единственный поток IDLE. В промежуточных кольцах живут пользовательские приложения.
* В пределах одного кольца потоки равноправны.
* Планировщик при выборе потока обходит все кольца по порядку, останавливаясь на первом потоке, кто хочет поработать. Если поток из нулевого кольца чем-то занят, то его может вытеснить только другой поток из нулевого кольца, и пока в нулевом кольце есть кто-то занятый, на последующие кольца планировщик даже смотреть не будет. Аналогично, до последнего кольца с потоком IDLE управление дойдёт, только если все остальные потоки уснули.
* Сам IDLE всегда занят вечным циклом из одной команды hlt. Если бы была поддержка ACPI, то вместо hlt было бы лучше переводить процессор в более высокие режимы энергосбережения, ибо hlt не влияет на шум от кулеров, но тема не об этом.
* В каждом кольце есть свой собственный текущий элемент. Если в кольце приложений после A идёт B, A только что закончил - уснул или закончился текущий квант - то следующим потоком из этого кольца будет B и в случае, если все вышележащие кольца спят, и в случае, если планировщик решит переключиться на кольцо повыше и потом вернуться.
* Ранее главный поток ядра был всегда занят циклом osloop. Мне пришлось поменять логику, иначе в полном соответствии с ранее сказанным остальные кольца бы не работали: разбить osloop на периодические куски - те, которые нужно выполнить в какой-то момент времени, - и непериодические - те, которые активируются, когда что-то произошло. Для периодических кусков я написала дополнительные функции "нужно ли этот кусок выполнять прямо сейчас". Для непериодических кусков я добавила вызов функции "разбудить главный поток" в моменты происхождения события. Кроме того, функция checkidle с нечеловеческой логикой исчезла.
* Прямо сейчас главный поток ядра продолжает пробуждаться каждый тик таймера, ибо этого требует сетевой стек с его бесконечным опросом сетевой карты. Все остальные события не требуют столько внимания.
* Основной эффект, зачем это всё надо: запустите десяток-другой демок trantest, пожирающих всё доступное им время, и попробуйте подвигать мышкой. На старых версиях ядра отчётливо чувствуются лаги с PS/2-мышками и ещё большие лаги с USB-мышками - сигналу от PS/2-мышки требуется в худшем случае дождаться, когда планировщик пройдёт по всему кольцу, а в среднем - по половине кольца, а сигнал от USB-мышки за то же время доберётся только до USB-потока, после чего понадобится ещё один проход по всему кольцу, чтобы главный поток ядра отрисовал курсор и послал все нужные сообщения. Я удивлена, что за всё время тестирования USB о таком поведении никто так и не сообщил.
* Поскольку мне это надо только для того, чтобы исключить торможение ядерных процессов при наличии большого количества приложений, то ядро не предоставляет API для управления приоритетом, все пользовательские приложения живут в одном кольце, всего колец, таким образом, три. Это легко поменять, если кому-то надо.

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: "Ночные" сборки KolibriOS
СообщениеДобавлено: Пн май 27, 2013 1:12 pm 
Не в сети

Зарегистрирован: Вс окт 30, 2011 6:43 pm
Сообщения: 1082
В svn3534 кнопка меню срабатывает только со второго раза после клика, например, по рабочему столу. И то же самое при выборе пунктов меню в приложении @menu: кликнули на пункт, появилось подменю, теперь нужно делать 2 клика для переключения на другой пункт.
В 3504 работает нормально.

Также падает при запуске GMON: page fault (kernel).
После запуска refscrn иконки не перерисовываются.


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 1:36 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Банально, но: респект и уважуха. \m/


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 1:39 pm 
Не в сети
KSoC/GSoC Student

Зарегистрирован: Ср июл 11, 2012 3:17 am
Сообщения: 224
Мне кажется или все стало намного логичнее и проще. Благодарю за проделанную работу!
Цитата:
Я удивлена, что за всё время тестирования USB о таком поведении никто так и не сообщил.

Думаю при тестах USB ни кто в принципе не загружал ядро на полную, люди были просто заняты другим: логи, флешки, мышки, разъемы).


Вернуться к началу
 Заголовок сообщения: Re: "Ночные" сборки KolibriOS
СообщениеДобавлено: Пн май 27, 2013 3:35 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
0CodErr писал(а):
В svn3534 кнопка меню срабатывает только со второго раза после клика, например, по рабочему столу. И то же самое при выборе пунктов меню в приложении @menu: кликнули на пункт, появилось подменю, теперь нужно делать 2 клика для переключения на другой пункт.
В 3504 работает нормально.

Оно и до r3534 при нескольких приложениях, отжирающих процессор, так же со второго раза работало. Первый клик - активация окна и запрос на перерисовку, уничтожающую кнопки. Только раньше был второй шанс: если приложение успевало отрисовать окно до следующего запуска главного потока И пользователь не успевал отпустить кнопку мыши за это же время, то обработка нажатия кнопки мыши запускалась снова.

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: "Ночные" сборки KolibriOS
СообщениеДобавлено: Пн май 27, 2013 3:59 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
0CodErr писал(а):
После запуска refscrn иконки не перерисовываются.

Они перерисовываются, но лишь после изменения соответствующих им кусков экрана. В ревизии 3533 такого не наблюдалось. Скорее всего приложение icon тупо не отлавливает обновление экрана, когда это делается через refscrn. Возможно поломалась последовательность событий при вызове ф.15.3.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 4:01 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
Я думаю сообщения начинающиеся с viewtopic.php?f=5&t=1602&start=835 нужно перенести в эту тему.
CleverMouse: таки да.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 4:10 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
0CodErr писал(а):
Также падает при запуске GMON: page fault (kernel).

Прямая работа с портами поломалась, я её вернула в r3535.

_________________
Сделаем мир лучше!


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 4:30 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
CleverMouse

Почти Minix-совский планировщик ? Мне нравится.
Ты не против, если я увеличу кол-во очередей хотя бы до 16 и сделаю битовую маску для быстрого поиска ожидающей исполнения очереди ?


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 4:55 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
До Minix'овского его ещё пилить и пилить. В Minix очереди и приоритеты динамические, спящие потоки в очередях не участвуют и время планировщика не расходуют, за полное использование своего кванта приоритет понижается; в том, что есть, очереди по-прежнему статические, - меняющиеся только при создании и уничтожении потока - включающие в себя в том числе спящие потоки и с фиксированными приоритетами.

Я не против дальнейших изменений, конечно.

_________________
Сделаем мир лучше!


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 6:11 pm 
Не в сети

Зарегистрирован: Вс фев 18, 2007 8:34 pm
Сообщения: 158
Поздравляю.

Serge, вместо битовой маски можно использовать динамический список очередей. Есть еще один нормальный вариант для небольшого числа очередей: список очередей статический; переключение выполняется только на соседнюю очередь "сверху" или "снизу"; в каждой очереди есть один служебный поток, который занимается тем, что сразу передает управление на след. поток в данной очереди или на тек. поток очереди "снизу", если он единственный в данной очереди; идентификатор такого потока в ячейке current очереди считается служебным значением, потому такая ситуация не противоречит правилу не передавать управление менее приоритетной очереди/потоку, пока есть более приоритетный.

CleverMouse, вовремя сделанное замечание. Статические кольцевые очереди - это очень плохо, тем более учитывая то, что до недавнего времени, как я понимаю, у вас такая очередь была одна. У меня все потоки, переходящие в состояние ожидания, сразу исключаются из run queue и заносятся в очереди ожидания к соотв. ресурсам. Все, что я говорил в пред. абзаце, предполагает наличие динамических очередей; упомянутые служебные потоки используются в том числе и для того, чтобы любая динамическаия очередь не опустевала полностью, даже если в ней нет ни одного рабочего потока.

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


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 7:51 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
0CodErr писал(а):
После запуска refscrn иконки не перерисовываются.

Это опять же из-за некорректного кода GUI:
Код:
; call change_task - because the application must have time to call f.15.8
        call    change_task

В r3536 я немного поправила код GUI, проблем с refscrn и необходимостью двойного клика по кнопке меню быть больше не должно.

_________________
Сделаем мир лучше!


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 7:55 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
Phantom84 писал(а):
Статические кольцевые очереди - это очень плохо

На самом деле не очень плохо. Это проблема типа "планировщик отъедает 10000 тактов, хотя ему хватило бы 1000" - цифры взяты с потолка, если что, - то есть важная на стадии проектирования, важная, если в системе тысячи потоков постоянно засыпают и просыпаются, но совершенно незаметная для конечного пользователя и абсолютно незначительная на фоне текущих проблем.
Phantom84 писал(а):
Еще нигде не заметил, как планируется решать основные проблемы приоритетного планирования - очень медленное продвижение или даже "замораживание" низкоприоритетных потоков при постоянном наличии работающих высокоприоритетных потоков, непрерывное ожидание высокоприоритетными потоками низкоприоритетных при постоянном наличии работающих "среднеприоритетных" потоков и т.п.

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

_________________
Сделаем мир лучше!


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 8:01 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Phantom84
В наших традициях резать (или пришивать?) хвост кошке по частям. Начали с приоритетов.


Вернуться к началу
СообщениеДобавлено: Пн май 27, 2013 8:10 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
CleverMouse писал(а):
0CodErr писал(а):
После запуска refscrn иконки не перерисовываются.

Это опять же из-за некорректного кода GUI:
Код:
; call change_task - because the application must have time to call f.15.8
        call    change_task

В r3536 я немного поправила код GUI, проблем с refscrn и необходимостью двойного клика по кнопке меню быть больше не должно.

Раньше (до ревизии 3534) без этого кода иконки не во всех случаях перерисовывались. Сейчас возможно и не нужно. Если не будет багрепоротов, значит все нормально.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 22 сообщения ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB