Board.KolibriOS.org

Official KolibriOS board
It is currently Mon May 20, 2019 5:56 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 81 posts ]  Go to page 1 2 3 4 5 6 Next
Author Message
PostPosted: Sun May 12, 2013 1:38 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Итак дано: кольцевой линейный планировщик.
Quote:
7. Планировщик циклически выделяет процессорное время всем активным потокам. Без всяких дополнительных ухищрений.

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

1. Берем зацикленное приложение, отжирающее все доступное ему процессорное время. Для примера я использовал зацикленный example.asm (есть на SVN).
Attachment:
1.png
1.png [ 5.28 KiB | Viewed 2991 times ]

Запускаем еще одну копию:
Attachment:
2.png
2.png [ 5.61 KiB | Viewed 2991 times ]

Что мы наблюдаем - вместо того чтобы разделить время поровну, планировщик выделил 2/3 времени первому приложению, и 1/3 второму.
Запускаем еще копию:
Attachment:
3.png
3.png [ 5.78 KiB | Viewed 2991 times ]

Опять неравноправие - первому досталась 1/2, а последующим двум 1/4 времени.

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


Top
   
PostPosted: Sun May 12, 2013 1:40 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Запускаем еще копию:
Attachment:
4.png
4.png [ 5.9 KiB | Viewed 2990 times ]

Опять неравноправие - первому досталась 1/3, а каждому последующему из трех 1/5 времени.
Теперь убиваем "коронованное" приложение.
Attachment:
5.png
5.png [ 5.76 KiB | Viewed 2990 times ]

Опять неравноправие - теперь уже второму, ставшему первым досталась 1/2, а каждому последующему из двух 1/4 времени.
Теперь вновь убиваем "коронованное" приложение.
Attachment:
6.png
6.png [ 5.55 KiB | Viewed 2990 times ]

Опять неравноправие - теперь уже третьему, ставшему первым досталась 2/3, а каждому последующему из двух 1/3 времени.

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


Top
   
PostPosted: Sun May 12, 2013 1:48 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Опять убиваем "коронованное" приложение.
Attachment:
7.png
7.png [ 5.34 KiB | Viewed 2990 times ]

Система как и положено выделяет "зажравшемуся" приложению все время.
Запускаем еще одну копию приложения:
Attachment:
8.png
8.png [ 5.72 KiB | Viewed 2990 times ]

Опять наблюдаем неравноправие.

З.Ы. Долой самодержавие, угнетение и поражение рядовых потоков в правах! Тапки должны принадлежать всем потокам равноправно и поочередно!
З.З.Ы. Использовалась сборка ревизии 3502.

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


Top
   
PostPosted: Sun May 12, 2013 2:18 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Возможно сообщение пользователями о случаях потребления одиночным потоком более 100% процессорного времени, как то коррелируют с этой багофичей.

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


Top
   
PostPosted: Sun May 12, 2013 3:22 am 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5047
Поправьте меня если что, как я понимаю, сейчас приложение может отобрать столько процессорного времени, сколько захочет. В результате зависшее приложение забирает 99%. С одной стороны это позволяет приложению требующему максимум ресурсов заполучить их все и закончить своё дело быстрее, с другой стороны другие запущенные приложения остаются не у дел.
Вопросы:
в других системах это реализовано также или по-другому?
Марио назвал это багофичей, т.к. подобное поведение даёт плюс приложениям требующим максимум процессорного времени? (например, видеоплееру)

_________________
Через тернии к звездам


Top
   
PostPosted: Sun May 12, 2013 4:22 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Leency wrote:
Марио назвал это багофичей, т.к. подобное поведение даёт плюс приложениям требующим максимум процессорного времени? (например, видеоплееру)

Это баг потому что так не должно быть и это же фича, потому что на протяжении десятка лет не исправлено. Это нельзя использовать с ожидаемым результатом и собственно до возрастания нагрузки близкой у критической эта багофича незаметна.

Собственно формулировка такова: увеличенный приоритет получает поток выполняющий одинаковое количество действий за квант времени по сравнению с другими подобными потоками, но имеющий наименьший номер слота. Последнее явно можно наблюдать на 8 картинке, где вновь запущенный поток стал "коронованным"- PID его является большим по значению.

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


Top
   
PostPosted: Tue May 14, 2013 10:04 am 
Offline
Kernel Developer
User avatar

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

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

Пока дело не дойдет до первого зависшего процесса: тот и чужое время хапнет, и свое законное по кольцу получит.


Top
   
PostPosted: Tue May 14, 2013 10:34 am 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 430
надо очередь задач мониторить прямо в шедулере, как вариант "смотреть" % загрузки прямо в нем.
Пусть он будет не тупым кольцевым переключателем, а "должен понимать", как необходимый минимум, кто допустим, превышает 40% загрузки CPU более чем трижды за последние кванты ему отведенные.
И если это зафиксировано, то такую задачу (поток), жестко ставить в конец очереди (кольца)...
Тогда "нормальные" задачи перетусуются вперед кольцаавтоматически

А если еще круче и ширше взлянуть на проблемы, куда попадает и эта, а она вливается в общее название таймеры. Там закопаны и nanoSleep, кванты, приоритеты, синхронные события...
Если нужен рецепт, то он тут был причем подточен именно под RTOS.
Т.к. если по тупому посмотреть из "готового" так и винда типа кое что переключалкой делать умеет, а вот временные события хотя бы более-менее и без висяков... неееееА!
Как базовая технология таймеро-квантового движка ядра, позволяющая культурно порешать ВСЕ эти проблемсы и узкие места есть на этом форуме.


Top
   
PostPosted: Tue May 14, 2013 6:42 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1328
VaStaNi
Сегодняшний планировщик - имхо самое то, что транку надо. Он конечно не РТ, но
1) очень простой, и
2) достаточно эффективный.

Да, эффективный. Простые процессы прогоняются в один квант, а (первое) прожорливое приложение получает сразу два.
В большинстве случаев ничего другого от планировщика и не требуется.


Top
   
PostPosted: Tue May 14, 2013 9:30 pm 
Offline
Kernel Developer

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

Проблема то собственно в том, что только одно прожорливое получает преимущество - технических преимущество должно делиться между всеми такими обжорами.

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


Top
   
PostPosted: Tue May 14, 2013 10:31 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Вроде дело в [DONT_SWITCH]:
Code:
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 и если флаг установлен пропускает переключение задачи на один тик. Таким образом поток, следующий за "легким" получает два кванта.


Top
   
PostPosted: Tue May 14, 2013 11:27 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Serge wrote:
Вроде дело в [DONT_SWITCH]:

Да, когда эти строки закомментированы , то эффек "коронации" пропадает. Остается подумать не повлияет ли это на что-нибудь другое. В kernel.asm это использовано:
Spoiler: Show
Code:
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. Напомню, что я внедрением того кода пытался добиться снижения времени отклика на завершение чтения/записи очередной порции данных, с целью ускорения обмена с жестким диском. Разумеется это изменяло логику работы планировщика и текущий поток работающий с жестким диском получал повышенный приоритет пред другими потоками, на время работы с жестким диском.

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


Last edited by Mario_r4 on Tue May 14, 2013 11:34 pm, edited 1 time in total.

Top
   
PostPosted: Tue May 14, 2013 11:33 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1328
Mario_r4 wrote:
art_zh wrote:
Простые процессы прогоняются в один квант, а (первое) прожорливое приложение получает сразу два.

Проблема то собственно в том, что только одно прожорливое получает преимущество - технических преимущество должно делиться между всеми такими обжорами.

Это такой фирменный "приоритетный диспетчер".
Хочешь чтобы у второго обжоры тоже были 2 кванта - запусти какую-нибудь пустышку сразу после первого.

А если без [DONT_SWITCH] - тогда тоже как-то нечестно получается, ведь от предыдущего кванта уже отгрызли несколько кусочков.


Last edited by art_zh on Tue May 14, 2013 11:38 pm, edited 1 time in total.

Top
   
PostPosted: Tue May 14, 2013 11:35 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
art_zh wrote:
Это такой фирменный "приоритетный диспетчер".
Хочешь чтобы у второго обжоры тоже были 2 кванта - запусти какую-нибудь пустышку сразу после первого.

Я описал возможные причины возникновения в дополнении к своему предыдущему посту.

З.Ы. Если ни у кого нет возражений, то я могу внести изменение в код планировщика. Если же Serge как обнаруживший причину, сам желает исправить, то не буду мешать.

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


Top
   
PostPosted: Tue May 14, 2013 11:39 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1328
я против: это не баг.
так лучше.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 81 posts ]  Go to page 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:  
cron
Powered by phpBB® Forum Software © phpBB Limited