Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Jul 20, 2019 9:08 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 22 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Mon May 27, 2013 12:52 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
В 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 для управления приоритетом, все пользовательские приложения живут в одном кольце, всего колец, таким образом, три. Это легко поменять, если кому-то надо.

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


Top
   
PostPosted: Mon May 27, 2013 1:12 pm 
Offline

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

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


Top
   
PostPosted: Mon May 27, 2013 1:36 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Банально, но: респект и уважуха. \m/


Top
   
PostPosted: Mon May 27, 2013 1:39 pm 
Offline
KSoC/GSoC Student

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

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


Top
   
PostPosted: Mon May 27, 2013 3:35 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
0CodErr wrote:
В svn3534 кнопка меню срабатывает только со второго раза после клика, например, по рабочему столу. И то же самое при выборе пунктов меню в приложении @menu: кликнули на пункт, появилось подменю, теперь нужно делать 2 клика для переключения на другой пункт.
В 3504 работает нормально.

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

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


Top
   
PostPosted: Mon May 27, 2013 3:59 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
0CodErr wrote:
После запуска refscrn иконки не перерисовываются.

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

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


Top
   
PostPosted: Mon May 27, 2013 4:01 pm 
Offline
Kernel Developer

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

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


Top
   
PostPosted: Mon May 27, 2013 4:10 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
0CodErr wrote:
Также падает при запуске GMON: page fault (kernel).

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

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


Top
   
PostPosted: Mon May 27, 2013 4:30 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
CleverMouse

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


Top
   
PostPosted: Mon May 27, 2013 4:55 pm 
Offline
Kernel Developer
User avatar

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

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

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


Top
   
PostPosted: Mon May 27, 2013 6:11 pm 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Поздравляю.

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

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

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


Top
   
PostPosted: Mon May 27, 2013 7:51 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
0CodErr wrote:
После запуска refscrn иконки не перерисовываются.

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

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

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


Top
   
PostPosted: Mon May 27, 2013 7:55 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
Phantom84 wrote:
Статические кольцевые очереди - это очень плохо

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

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

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


Top
   
PostPosted: Mon May 27, 2013 8:01 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Phantom84
В наших традициях резать (или пришивать?) хвост кошке по частям. Начали с приоритетов.


Top
   
PostPosted: Mon May 27, 2013 8:10 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
CleverMouse wrote:
0CodErr wrote:
После запуска refscrn иконки не перерисовываются.

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

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

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

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 22 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited