Page 1 of 6
Работа планировщика задач
Posted: Sun May 12, 2013 1:38 am
by Mario_r4
Итак дано: кольцевой линейный планировщик.
Однако имеются странности, пару разу упоминавшиеся в сообщениях на этом форуме, давным давно было, но так и осталась багофича.
1. Берем зацикленное приложение, отжирающее все доступное ему процессорное время. Для примера я использовал зацикленный example.asm (есть на SVN).
-
1.png (5.28 KiB)
Viewed 9595 times
Запускаем еще одну копию:
-
2.png (5.61 KiB)
Viewed 9595 times
Что мы наблюдаем - вместо того чтобы разделить время поровну, планировщик выделил 2/3 времени первому приложению, и 1/3 второму.
Запускаем еще копию:
-
3.png (5.78 KiB)
Viewed 9595 times
Опять неравноправие - первому досталась 1/2, а последующим двум 1/4 времени.
Re: Работа планировщика задач
Posted: Sun May 12, 2013 1:40 am
by Mario_r4
Запускаем еще копию:
-
4.png (5.9 KiB)
Viewed 9594 times
Опять неравноправие - первому досталась 1/3, а каждому последующему из трех 1/5 времени.
Теперь убиваем "коронованное" приложение.
-
5.png (5.76 KiB)
Viewed 9594 times
Опять неравноправие - теперь уже второму, ставшему первым досталась 1/2, а каждому последующему из двух 1/4 времени.
Теперь вновь убиваем "коронованное" приложение.
-
6.png (5.55 KiB)
Viewed 9594 times
Опять неравноправие - теперь уже третьему, ставшему первым досталась 2/3, а каждому последующему из двух 1/3 времени.
Re: Работа планировщика задач
Posted: Sun May 12, 2013 1:48 am
by Mario_r4
Опять убиваем "коронованное" приложение.
-
7.png (5.34 KiB)
Viewed 9594 times
Система как и положено выделяет "зажравшемуся" приложению все время.
Запускаем еще одну копию приложения:
-
8.png (5.72 KiB)
Viewed 9594 times
Опять наблюдаем неравноправие.
З.Ы. Долой самодержавие, угнетение и поражение рядовых потоков в правах! Тапки должны принадлежать всем потокам равноправно и поочередно!
З.З.Ы. Использовалась сборка ревизии 3502.
Re: Работа планировщика задач
Posted: Sun May 12, 2013 2:18 am
by Mario_r4
Возможно сообщение пользователями о случаях потребления одиночным потоком более 100% процессорного времени, как то коррелируют с этой багофичей.
Re: Работа планировщика задач
Posted: Sun May 12, 2013 3:22 am
by Leency
Поправьте меня если что, как я понимаю, сейчас приложение может отобрать столько процессорного времени, сколько захочет. В результате зависшее приложение забирает 99%. С одной стороны это позволяет приложению требующему максимум ресурсов заполучить их все и закончить своё дело быстрее, с другой стороны другие запущенные приложения остаются не у дел.
Вопросы:
в других системах это реализовано также или по-другому?
Марио назвал это багофичей, т.к. подобное поведение даёт плюс приложениям требующим максимум процессорного времени? (например, видеоплееру)
Re: Работа планировщика задач
Posted: Sun May 12, 2013 4:22 am
by Mario_r4
Leency wrote:Марио назвал это багофичей, т.к. подобное поведение даёт плюс приложениям требующим максимум процессорного времени? (например, видеоплееру)
Это баг потому что так не должно быть и это же фича, потому что на протяжении десятка лет не исправлено. Это нельзя использовать с ожидаемым результатом и собственно до возрастания нагрузки близкой у критической эта багофича незаметна.
Собственно формулировка такова: увеличенный приоритет получает поток выполняющий одинаковое количество действий за квант времени по сравнению с другими подобными потоками, но имеющий наименьший номер слота. Последнее явно можно наблюдать на 8 картинке, где вновь запущенный поток стал "коронованным"- PID его является большим по значению.
Re: Работа планировщика задач
Posted: Tue May 14, 2013 10:04 am
by art_zh
Это не баг и не фича, все именно так, как должно быть в кольцевом планировщике.
Про остальные процессы забыл? Они тоже получают свой 10-миллисекундный квант времени, используют сотню тактов - и возвращают его назад планировщику. Так один квант расшаривается между всеми неактивными процессами.
Пока дело не дойдет до первого зависшего процесса: тот и чужое время хапнет, и свое законное по кольцу получит.
Re: Работа планировщика задач
Posted: Tue May 14, 2013 10:34 am
by VaStaNi
надо очередь задач
мониторить прямо в шедулере, как вариант "смотреть"
% загрузки прямо в нем.
Пусть он будет не тупым кольцевым переключателем, а "должен понимать", как необходимый минимум, кто допустим, превышает 40% загрузки CPU более чем трижды за последние кванты ему отведенные.
И если это зафиксировано, то такую задачу (поток),
жестко ставить в конец очереди (кольца)...
Тогда "нормальные" задачи перетусуются вперед кольцаавтоматически
А если еще круче и ширше взлянуть на проблемы, куда попадает и эта, а она вливается в общее название
таймеры. Там закопаны и nanoSleep, кванты, приоритеты, синхронные события...
Если нужен рецепт, то он тут был причем подточен именно под RTOS.
Т.к. если по тупому посмотреть из "готового" так и винда типа кое что переключалкой делать умеет, а вот временные события хотя бы более-менее и без висяков... неееееА!
Как базовая технология
таймеро-квантового движка ядра, позволяющая культурно порешать ВСЕ эти проблемсы и узкие места есть на этом форуме.
Re: Работа планировщика задач
Posted: Tue May 14, 2013 6:42 pm
by art_zh
VaStaNi
Сегодняшний планировщик - имхо самое то, что транку надо. Он конечно не РТ, но
1) очень простой, и
2) достаточно эффективный.
Да, эффективный. Простые процессы прогоняются в один квант, а (первое) прожорливое приложение получает сразу два.
В большинстве случаев ничего другого от планировщика и не требуется.
Re: Работа планировщика задач
Posted: Tue May 14, 2013 9:30 pm
by Mario_r4
art_zh wrote:Простые процессы прогоняются в один квант, а (первое) прожорливое приложение получает сразу два.
Проблема то собственно в том, что только одно прожорливое получает преимущество - технических преимущество должно делиться между всеми такими обжорами.
Re: Работа планировщика задач
Posted: Tue May 14, 2013 10:31 pm
by Serge
Вроде дело в [DONT_SWITCH]:
Code: Select all
align 4
change_task:
pushfd
cli
pushad
call find_next_task
jz .return ; the same task -> skip switch
@@:
mov byte[DONT_SWITCH], 1
call do_change_task
.return:
popad
popfd
ret
irq0:
pushad
Mov ds, ax, app_data
mov es, ax
inc [timer_ticks]
mov eax, [timer_ticks]
call playNote ; <<<--- Speaker driver
sub eax, [next_usage_update]
cmp eax, 100
jb .nocounter
add [next_usage_update], 100
call updatecputimes
.nocounter:
xor ecx, ecx ; send End Of Interrupt signal
call irq_eoi
btr dword[DONT_SWITCH], 0
jc .return
call find_next_task
jz .return ; if there is only one running process
call do_change_task
.return:
popad
iretd
Если поток не использовал свой квант полностью, он вызывает change_task, а та устанавливает DONT_SWITCH в 1. Обработчик irq0 проверяет DONT_SWITCH и если флаг установлен пропускает переключение задачи на один тик. Таким образом поток, следующий за "легким" получает два кванта.
Re: Работа планировщика задач
Posted: Tue May 14, 2013 11:27 pm
by Mario_r4
Serge wrote:Вроде дело в [DONT_SWITCH]:
Да, когда эти строки закомментированы , то эффек "коронации" пропадает. Остается подумать не повлияет ли это на что-нибудь другое. В kernel.asm это использовано:
Spoiler:
Code: Select all
set_variables:
mov ecx, 0x16 ; flush port 0x60
.fl60:
in al, 0x60
loop .fl60
push eax
mov ax, [BOOT_VAR+BOOT_Y_RES]
shr ax, 1
shl eax, 16
mov ax, [BOOT_VAR+BOOT_X_RES]
shr ax, 1
mov [MOUSE_X], eax
xor eax, eax
mov [BTN_ADDR], dword BUTTON_INFO ; address of button list
mov byte [MOUSE_BUFF_COUNT], al ; mouse buffer
mov byte [KEY_COUNT], al ; keyboard buffer
mov byte [BTN_COUNT], al ; button buffer
; mov [MOUSE_X],dword 100*65536+100 ; mouse x/y
;!! IP 04.02.2005:
mov byte [DONT_SWITCH], al; change task if possible
pop eax
ret
Однако никаких деструктивных последствий от исключения проверки [DONT_SWITCH] я не обнаружил.
Я могу предположить, что код проверки попал туда еще во время внедрения DMA доступа к жестким дискам. Которые ты закомментировал в обработчиках прерываний hdd_irq14 и hdd_irq15. Напомню, что я внедрением того кода пытался добиться снижения времени отклика на завершение чтения/записи очередной порции данных, с целью ускорения обмена с жестким диском. Разумеется это изменяло логику работы планировщика и текущий поток работающий с жестким диском получал повышенный приоритет пред другими потоками, на время работы с жестким диском.
Re: Работа планировщика задач
Posted: Tue May 14, 2013 11:33 pm
by art_zh
Mario_r4 wrote:art_zh wrote:Простые процессы прогоняются в один квант, а (первое) прожорливое приложение получает сразу два.
Проблема то собственно в том, что только одно прожорливое получает преимущество - технических преимущество должно делиться между всеми такими обжорами.
Это такой фирменный "приоритетный диспетчер".
Хочешь чтобы у второго обжоры тоже были 2 кванта - запусти какую-нибудь пустышку сразу после первого.
А если без [DONT_SWITCH] - тогда тоже как-то нечестно получается, ведь от предыдущего кванта уже отгрызли несколько кусочков.
Re: Работа планировщика задач
Posted: Tue May 14, 2013 11:35 pm
by Mario_r4
art_zh wrote:Это такой фирменный "приоритетный диспетчер".
Хочешь чтобы у второго обжоры тоже были 2 кванта - запусти какую-нибудь пустышку сразу после первого.
Я описал возможные причины возникновения в дополнении к своему предыдущему посту.
З.Ы. Если ни у кого нет возражений, то я могу внести изменение в код планировщика. Если же Serge как обнаруживший причину, сам желает исправить, то не буду мешать.
Re: Работа планировщика задач
Posted: Tue May 14, 2013 11:39 pm
by art_zh
я против: это не баг.
так лучше.