Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Aug 25, 2019 6:44 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 81 posts ]  Go to page Previous 1 2 3 4 5 6 Next
Author Message
PostPosted: Wed May 15, 2013 12:37 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Простое увеличение периода переключения задач ничего не даст.

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

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


Last edited by art_zh on Wed May 15, 2013 12:43 am, edited 3 times in total.

Top
   
PostPosted: Wed May 15, 2013 12:39 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario_r4
Там это скорее всего задаётся программистом, как и алгоритм планировщика.

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


Last edited by Serge on Wed May 15, 2013 12:44 am, edited 1 time in total.

Top
   
PostPosted: Wed May 15, 2013 12:41 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
art_zh wrote:
Просое увеличение периода переключения задач ничего не даст.

Почему ничего не даст? Сами же говорили с Сергеем про то как будут поделены проценты между соседями.

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


Top
   
PostPosted: Wed May 15, 2013 12:44 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Serge wrote:
Нам тоже понадобится планировщик, если увеличить квант до 20 - 50 мс.

Давай пока не будем бросаться в крайности.
1. Что решаем насчет "убрать DONT_SWITCH"?
2. Нужно ли внедрение повышения частоты таймера в текущем виде?

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


Top
   
PostPosted: Wed May 15, 2013 12:54 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Потому что если таймер будет тикать слишком быстро - будут большие потери времени на обработку каждого IRQ,
а если не слишком быстро - то проблема как была, так и останется:
для тебя 200% у первого процесса - аццкая несправедливость, а кто-то скажет что и 110% зло.

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


Top
   
PostPosted: Wed May 15, 2013 1:00 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh
Идея неплоха, но тогда таймер сбивается и нафиг летят всякие wait_event_timeout(). То есть нужен отдельный таймер с блекджеком, например из LAPIC.


Top
   
PostPosted: Wed May 15, 2013 1:00 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Serge
- да.
я тоже про LAPIC подумал. Этот точно не собьется.

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


Last edited by art_zh on Wed May 15, 2013 1:15 am, edited 2 times in total.

Top
   
PostPosted: Wed May 15, 2013 1:06 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario_r4
1. Предлагаю убрать и посмотреть, что получится.
2. Только с одновременным увеличением числа тиков в кванте. Ещё надо учесть, что всякие delay() cчитают 1тик = 0.01с


Top
   
PostPosted: Wed May 15, 2013 1:30 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
А еще если уж такая фича имеет место быть - надо довести ее до абсурда уровня полноценного приоритетного планировщика:

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

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


Top
   
PostPosted: Wed May 15, 2013 1:41 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
art_zh wrote:
А еще если уж такая фича имеет место быть - надо довести ее до абсурда уровня полноценного приоритетного планировщика:

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

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

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


Top
   
PostPosted: Wed May 15, 2013 1:49 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Mario_r4 wrote:
1. Как ты видишь механизм запроса? Отдельная таблица, куда заносятся изменения в запросах приложений через специальную сисфункцию ядра?
2. Боюсь такой механизм как минимум парализует графическую подсистему.


1. можно через отдельную подфункцию 12-й, можно вообще вынести в заголовок KEX-файла нового формата (все еще грузимся со старым заголовком MINJET01, но ведь никто не запрещает продумать что-то свое, так?)

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


Top
   
PostPosted: Wed May 15, 2013 1:52 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Еще раз проверив все на реальной машине я внес изменение в SVN r. 3504.

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

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


Top
   
PostPosted: Wed May 15, 2013 1:54 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
art_zh wrote:
2. Нет, графическая надсистема совершенно независима от планировщика.

O RLY? Как насчет перемещения указателя курсора?

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


Top
   
PostPosted: Wed May 15, 2013 2:05 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Mario
завтра специально придумаю какой-нибудь квантовый фифект. во славу релятивисткой физики.

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


Top
   
PostPosted: Wed May 15, 2013 2:13 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
art_zh wrote:
указатель мыши вроде только оконный стек перебирает емнип? ему длительность текущего процесса должна быть до фонаря.

Ты мыслишь не в том направлении. Вот двигает пользователь мышку, а курсор не двигается... а потом внезапно ПРЫГ на новую позицию! А все почему? Потому что велосипеду WARP двигатель приделали, драйвер мыши работает стабильно и меняет координаты, а MAIN LOOP терпеливо ждет когда FHT перестанет кошмарить планировщик задач... чтобы наконец нарисовать указатель в новой позиции.

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 81 posts ]  Go to page Previous 1 2 3 4 5 6 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


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:  
Powered by phpBB® Forum Software © phpBB Limited