Простое увеличение периода переключения задач ничего не даст.
Проблема решается переходом от равнопериодических прерываний таймера к программируемым.
Впрочем, и проблемы-то никакой нет (мы же пока не позиционируем себя как RTOS?) - каждый процесс гарантированно получает 1 полный квант не реже чем через N квантов (N=число процессов). В реале - гораздо чаще, чем через N квантов.
Плюс бонус, если предыдущий квант не был до конца использован.
Работа планировщика задач
-
Last edited by art_zh on Wed May 15, 2013 12:43 am, edited 3 times in total.
Mario_r4
Там это скорее всего задаётся программистом, как и алгоритм планировщика.
Нам тоже понадобится планировщик, если увеличить квант до 20 - 50 мс.
И ничто не мешает сделать несколько разных алгоритмов, на выбор программиста.
Там это скорее всего задаётся программистом, как и алгоритм планировщика.
Нам тоже понадобится планировщик, если увеличить квант до 20 - 50 мс.
И ничто не мешает сделать несколько разных алгоритмов, на выбор программиста.
Last edited by Serge on Wed May 15, 2013 12:44 am, edited 1 time in total.
Почему ничего не даст? Сами же говорили с Сергеем про то как будут поделены проценты между соседями.art_zh wrote:Просое увеличение периода переключения задач ничего не даст.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Давай пока не будем бросаться в крайности.Serge wrote:Нам тоже понадобится планировщик, если увеличить квант до 20 - 50 мс.
1. Что решаем насчет "убрать DONT_SWITCH"?
2. Нужно ли внедрение повышения частоты таймера в текущем виде?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Потому что если таймер будет тикать слишком быстро - будут большие потери времени на обработку каждого IRQ,
а если не слишком быстро - то проблема как была, так и останется:
для тебя 200% у первого процесса - аццкая несправедливость, а кто-то скажет что и 110% зло.
Ели уж решать, так принципиально:
- каждое переключение задачи перезапускает интервальный таймер на новый квант,
- неиспользованный квант сбрасывает таймер, переключает задачу и заново перезапускает таймер.
а если не слишком быстро - то проблема как была, так и останется:
для тебя 200% у первого процесса - аццкая несправедливость, а кто-то скажет что и 110% зло.
Ели уж решать, так принципиально:
- каждое переключение задачи перезапускает интервальный таймер на новый квант,
- неиспользованный квант сбрасывает таймер, переключает задачу и заново перезапускает таймер.
art_zh
Идея неплоха, но тогда таймер сбивается и нафиг летят всякие wait_event_timeout(). То есть нужен отдельный таймер с блекджеком, например из LAPIC.
Идея неплоха, но тогда таймер сбивается и нафиг летят всякие wait_event_timeout(). То есть нужен отдельный таймер с блекджеком, например из LAPIC.
Serge
- да.
я тоже про LAPIC подумал. Этот точно не собьется.
Mario
1) можешь конечно убрать, но сдается мне что не пройдет и недели, как у кого-то где-то что-то невоспроизводимое выползет, и придется откатывать всё взад.
2) было бы интересно поиграть с планировщиком на перепрограммируемом интервальном таймере, но на старых пнях и селеронах этот код точно не покатит.
- да.
я тоже про LAPIC подумал. Этот точно не собьется.
Mario
1) можешь конечно убрать, но сдается мне что не пройдет и недели, как у кого-то где-то что-то невоспроизводимое выползет, и придется откатывать всё взад.
2) было бы интересно поиграть с планировщиком на перепрограммируемом интервальном таймере, но на старых пнях и селеронах этот код точно не покатит.
Last edited by art_zh on Wed May 15, 2013 1:15 am, edited 2 times in total.
Mario_r4
1. Предлагаю убрать и посмотреть, что получится.
2. Только с одновременным увеличением числа тиков в кванте. Ещё надо учесть, что всякие delay() cчитают 1тик = 0.01с
1. Предлагаю убрать и посмотреть, что получится.
2. Только с одновременным увеличением числа тиков в кванте. Ещё надо учесть, что всякие delay() cчитают 1тик = 0.01с
А еще если уж такая фича имеет место быть - надо довести ее до абсурда уровня полноценного приоритетного планировщика:
- вместо сброса/установки единственного бита - проводить декремент содержимого DONT_SWITCH. чтобы прожорливые приложения могли запрашиавать (и по возможности получать) более высокий приоритет, не переключаясь (максимум) в течение 10 квантов.
Скажем, сейчас FHT тратит на мегапиксельную картинку 400..440 миллисекунд. Если бы система могла в течение 5 квантов не переключать контекст и не ломала бы кэш, наверное можно было бы сократить время преобразования. Или хотя бы уменьшить разброс по времени.
- вместо сброса/установки единственного бита - проводить декремент содержимого DONT_SWITCH. чтобы прожорливые приложения могли запрашиавать (и по возможности получать) более высокий приоритет, не переключаясь (максимум) в течение 10 квантов.
Скажем, сейчас FHT тратит на мегапиксельную картинку 400..440 миллисекунд. Если бы система могла в течение 5 квантов не переключать контекст и не ломала бы кэш, наверное можно было бы сократить время преобразования. Или хотя бы уменьшить разброс по времени.
1. Как ты видишь механизм запроса? Отдельная таблица, куда заносятся изменения в запросах приложений через специальную сисфункцию ядра?art_zh wrote:А еще если уж такая фича имеет место быть - надо довести ее доабсурдауровня полноценного приоритетного планировщика:
- вместо сброса/установки единственного бита - проводить декремент содержимого DONT_SWITCH. чтобы прожорливые приложения могли запрашиавать (и по возможности получать) более высокий приоритет, не переключаясь (максимум) в течение 10 квантов.
2. Боюсь такой механизм как минимум парализует графическую подсистему.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
1. можно через отдельную подфункцию 12-й, можно вообще вынести в заголовок KEX-файла нового формата (все еще грузимся со старым заголовком MINJET01, но ведь никто не запрещает продумать что-то свое, так?)Mario_r4 wrote: 1. Как ты видишь механизм запроса? Отдельная таблица, куда заносятся изменения в запросах приложений через специальную сисфункцию ядра?
2. Боюсь такой механизм как минимум парализует графическую подсистему.
2. Нет, графическая надсистема совершенно независима от планировщика.
Еще раз проверив все на реальной машине я внес изменение в SVN r. 3504.
Запускал Gears вперемешку с Gmon на достаточно дохленьком RoverBook U800 и никаких эффектов квантовой физики и специальной теории относительности не наблюдал. Что не исключает их наличие, ибо человеческий глаз вкупе с мозгом инструмент не самый точный.
Запускал Gears вперемешку с Gmon на достаточно дохленьком RoverBook U800 и никаких эффектов квантовой физики и специальной теории относительности не наблюдал. Что не исключает их наличие, ибо человеческий глаз вкупе с мозгом инструмент не самый точный.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
O RLY? Как насчет перемещения указателя курсора?art_zh wrote:2. Нет, графическая надсистема совершенно независима от планировщика.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Mario
завтра специально придумаю какой-нибудь квантовый фифект. во славу релятивисткой физики.
указатель мыши вроде только оконный стек перебирает емнип? ему длительность текущего процесса должна быть до фонаря.
завтра специально придумаю какой-нибудь квантовый фифект. во славу релятивисткой физики.
указатель мыши вроде только оконный стек перебирает емнип? ему длительность текущего процесса должна быть до фонаря.
Ты мыслишь не в том направлении. Вот двигает пользователь мышку, а курсор не двигается... а потом внезапно ПРЫГ на новую позицию! А все почему? Потому чтоart_zh wrote:указатель мыши вроде только оконный стек перебирает емнип? ему длительность текущего процесса должна быть до фонаря.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Who is online
Users browsing this forum: No registered users and 33 guests