Board.KolibriOS.org

Итак дано: кольцевой линейный планировщик.

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

1. Берем зацикленное приложение, отжирающее все доступное ему процессорное время. Для примера я использовал зацикленный example.asm (есть на SVN).

Запускаем еще одну копию:

Что мы наблюдаем - вместо того чтобы разделить время поровну, планировщик выделил 2/3 времени первому приложению, и 1/3 второму.
Запускаем еще копию:

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

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

Запускаем еще копию:

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

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

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

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

Опять убиваем "коронованное" приложение.

Система как и положено выделяет "зажравшемуся" приложению все время.
Запускаем еще одну копию приложения:

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

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

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

Возможно сообщение пользователями о случаях потребления одиночным потоком более 100% процессорного времени, как то коррелируют с этой багофичей.

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

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

_________________
Звиздеть не мешки ворочать

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

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

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

Это не баг и не фича, все именно так, как должно быть в кольцевом планировщике.

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

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

надо очередь задач мониторить прямо в шедулере, как вариант "смотреть" % загрузки прямо в нем.
Пусть он будет не тупым кольцевым переключателем, а "должен понимать", как необходимый минимум, кто допустим, превышает 40% загрузки CPU более чем трижды за последние кванты ему отведенные.
И если это зафиксировано, то такую задачу (поток), жестко ставить в конец очереди (кольца)...
Тогда "нормальные" задачи перетусуются вперед кольцаавтоматически

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

VaStaNi
Сегодняшний планировщик - имхо самое то, что транку надо. Он конечно не РТ, но
1) очень простой, и
2) достаточно эффективный.

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

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

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

Вроде дело в [DONT_SWITCH]:

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 и если флаг установлен пропускает переключение задачи на один тик. Таким образом поток, следующий за "легким" получает два кванта.

Да, когда эти строки закомментированы , то эффек "коронации" пропадает. Остается подумать не повлияет ли это на что-нибудь другое. В kernel.asm это использовано:

Однако никаких деструктивных последствий от исключения проверки [DONT_SWITCH] я не обнаружил.

Я могу предположить, что код проверки попал туда еще во время внедрения DMA доступа к жестким дискам. Которые ты закомментировал в обработчиках прерываний hdd_irq14 и hdd_irq15. Напомню, что я внедрением того кода пытался добиться снижения времени отклика на завершение чтения/записи очередной порции данных, с целью ускорения обмена с жестким диском. Разумеется это изменяло логику работы планировщика и текущий поток работающий с жестким диском получал повышенный приоритет пред другими потоками, на время работы с жестким диском.

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

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

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

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

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

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

я против: это не баг.
так лучше.