Page 3 of 6

Re: Работа планировщика задач

Posted: Wed May 15, 2013 12:37 am
by art_zh
Простое увеличение периода переключения задач ничего не даст.

Проблема решается переходом от равнопериодических прерываний таймера к программируемым.

Впрочем, и проблемы-то никакой нет (мы же пока не позиционируем себя как RTOS?) - каждый процесс гарантированно получает 1 полный квант не реже чем через N квантов (N=число процессов). В реале - гораздо чаще, чем через N квантов.
Плюс бонус, если предыдущий квант не был до конца использован.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 12:39 am
by Serge
Mario_r4
Там это скорее всего задаётся программистом, как и алгоритм планировщика.

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

Re: Работа планировщика задач

Posted: Wed May 15, 2013 12:41 am
by Mario_r4
art_zh wrote:Просое увеличение периода переключения задач ничего не даст.
Почему ничего не даст? Сами же говорили с Сергеем про то как будут поделены проценты между соседями.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 12:44 am
by Mario_r4
Serge wrote:Нам тоже понадобится планировщик, если увеличить квант до 20 - 50 мс.
Давай пока не будем бросаться в крайности.
1. Что решаем насчет "убрать DONT_SWITCH"?
2. Нужно ли внедрение повышения частоты таймера в текущем виде?

Re: Работа планировщика задач

Posted: Wed May 15, 2013 12:54 am
by art_zh
Потому что если таймер будет тикать слишком быстро - будут большие потери времени на обработку каждого IRQ,
а если не слишком быстро - то проблема как была, так и останется:
для тебя 200% у первого процесса - аццкая несправедливость, а кто-то скажет что и 110% зло.

Ели уж решать, так принципиально:
- каждое переключение задачи перезапускает интервальный таймер на новый квант,
- неиспользованный квант сбрасывает таймер, переключает задачу и заново перезапускает таймер.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 1:00 am
by Serge
art_zh
Идея неплоха, но тогда таймер сбивается и нафиг летят всякие wait_event_timeout(). То есть нужен отдельный таймер с блекджеком, например из LAPIC.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 1:00 am
by art_zh
Serge
- да.
я тоже про LAPIC подумал. Этот точно не собьется.

Mario
1) можешь конечно убрать, но сдается мне что не пройдет и недели, как у кого-то где-то что-то невоспроизводимое выползет, и придется откатывать всё взад.
2) было бы интересно поиграть с планировщиком на перепрограммируемом интервальном таймере, но на старых пнях и селеронах этот код точно не покатит.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 1:06 am
by Serge
Mario_r4
1. Предлагаю убрать и посмотреть, что получится.
2. Только с одновременным увеличением числа тиков в кванте. Ещё надо учесть, что всякие delay() cчитают 1тик = 0.01с

Re: Работа планировщика задач

Posted: Wed May 15, 2013 1:30 am
by art_zh
А еще если уж такая фича имеет место быть - надо довести ее до абсурда уровня полноценного приоритетного планировщика:

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

Скажем, сейчас FHT тратит на мегапиксельную картинку 400..440 миллисекунд. Если бы система могла в течение 5 квантов не переключать контекст и не ломала бы кэш, наверное можно было бы сократить время преобразования. Или хотя бы уменьшить разброс по времени.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 1:41 am
by Mario_r4
art_zh wrote:А еще если уж такая фича имеет место быть - надо довести ее до абсурда уровня полноценного приоритетного планировщика:

- вместо сброса/установки единственного бита - проводить декремент содержимого DONT_SWITCH. чтобы прожорливые приложения могли запрашиавать (и по возможности получать) более высокий приоритет, не переключаясь (максимум) в течение 10 квантов.
1. Как ты видишь механизм запроса? Отдельная таблица, куда заносятся изменения в запросах приложений через специальную сисфункцию ядра?
2. Боюсь такой механизм как минимум парализует графическую подсистему.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 1:49 am
by art_zh
Mario_r4 wrote: 1. Как ты видишь механизм запроса? Отдельная таблица, куда заносятся изменения в запросах приложений через специальную сисфункцию ядра?
2. Боюсь такой механизм как минимум парализует графическую подсистему.
1. можно через отдельную подфункцию 12-й, можно вообще вынести в заголовок KEX-файла нового формата (все еще грузимся со старым заголовком MINJET01, но ведь никто не запрещает продумать что-то свое, так?)

2. Нет, графическая надсистема совершенно независима от планировщика.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 1:52 am
by Mario_r4
Еще раз проверив все на реальной машине я внес изменение в SVN r. 3504.

Запускал Gears вперемешку с Gmon на достаточно дохленьком RoverBook U800 и никаких эффектов квантовой физики и специальной теории относительности не наблюдал. Что не исключает их наличие, ибо человеческий глаз вкупе с мозгом инструмент не самый точный.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 1:54 am
by Mario_r4
art_zh wrote:2. Нет, графическая надсистема совершенно независима от планировщика.
O RLY? Как насчет перемещения указателя курсора?

Re: Работа планировщика задач

Posted: Wed May 15, 2013 2:05 am
by art_zh
Mario
завтра специально придумаю какой-нибудь квантовый фифект. во славу релятивисткой физики.

указатель мыши вроде только оконный стек перебирает емнип? ему длительность текущего процесса должна быть до фонаря.

Re: Работа планировщика задач

Posted: Wed May 15, 2013 2:13 am
by Mario_r4
art_zh wrote:указатель мыши вроде только оконный стек перебирает емнип? ему длительность текущего процесса должна быть до фонаря.
Ты мыслишь не в том направлении. Вот двигает пользователь мышку, а курсор не двигается... а потом внезапно ПРЫГ на новую позицию! А все почему? Потому что велосипеду WARP двигатель приделали, драйвер мыши работает стабильно и меняет координаты, а MAIN LOOP терпеливо ждет когда FHT перестанет кошмарить планировщик задач... чтобы наконец нарисовать указатель в новой позиции.