Работа планировщика задач

Kernel architecture questions
  • Запускаем еще копию:
    4.png
    4.png (5.9 KiB)
    Viewed 9429 times
    Опять неравноправие - первому досталась 1/3, а каждому последующему из трех 1/5 времени.
    Теперь убиваем "коронованное" приложение.
    5.png
    5.png (5.76 KiB)
    Viewed 9429 times
    Опять неравноправие - теперь уже второму, ставшему первым досталась 1/2, а каждому последующему из двух 1/4 времени.
    Теперь вновь убиваем "коронованное" приложение.
    6.png
    6.png (5.55 KiB)
    Viewed 9429 times
    Опять неравноправие - теперь уже третьему, ставшему первым досталась 2/3, а каждому последующему из двух 1/3 времени.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Опять убиваем "коронованное" приложение.
    7.png
    7.png (5.34 KiB)
    Viewed 9429 times
    Система как и положено выделяет "зажравшемуся" приложению все время.
    Запускаем еще одну копию приложения:
    8.png
    8.png (5.72 KiB)
    Viewed 9429 times
    Опять наблюдаем неравноправие.

    З.Ы. Долой самодержавие, угнетение и поражение рядовых потоков в правах! Тапки должны принадлежать всем потокам равноправно и поочередно!
    З.З.Ы. Использовалась сборка ревизии 3502.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Возможно сообщение пользователями о случаях потребления одиночным потоком более 100% процессорного времени, как то коррелируют с этой багофичей.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Поправьте меня если что, как я понимаю, сейчас приложение может отобрать столько процессорного времени, сколько захочет. В результате зависшее приложение забирает 99%. С одной стороны это позволяет приложению требующему максимум ресурсов заполучить их все и закончить своё дело быстрее, с другой стороны другие запущенные приложения остаются не у дел.
    Вопросы:
    в других системах это реализовано также или по-другому?
    Марио назвал это багофичей, т.к. подобное поведение даёт плюс приложениям требующим максимум процессорного времени? (например, видеоплееру)
    Из хаоса в космос
  • Leency wrote:Марио назвал это багофичей, т.к. подобное поведение даёт плюс приложениям требующим максимум процессорного времени? (например, видеоплееру)
    Это баг потому что так не должно быть и это же фича, потому что на протяжении десятка лет не исправлено. Это нельзя использовать с ожидаемым результатом и собственно до возрастания нагрузки близкой у критической эта багофича незаметна.

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

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

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

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

    Да, эффективный. Простые процессы прогоняются в один квант, а (первое) прожорливое приложение получает сразу два.
    В большинстве случаев ничего другого от планировщика и не требуется.
  • art_zh wrote:Простые процессы прогоняются в один квант, а (первое) прожорливое приложение получает сразу два.
    Проблема то собственно в том, что только одно прожорливое получает преимущество - технических преимущество должно делиться между всеми такими обжорами.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Вроде дело в [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 и если флаг установлен пропускает переключение задачи на один тик. Таким образом поток, следующий за "легким" получает два кванта.
  • 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. Напомню, что я внедрением того кода пытался добиться снижения времени отклика на завершение чтения/записи очередной порции данных, с целью ускорения обмена с жестким диском. Разумеется это изменяло логику работы планировщика и текущий поток работающий с жестким диском получал повышенный приоритет пред другими потоками, на время работы с жестким диском.
    Last edited by Mario_r4 on Tue May 14, 2013 11:34 pm, edited 1 time in total.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • 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.
  • art_zh wrote:Это такой фирменный "приоритетный диспетчер".
    Хочешь чтобы у второго обжоры тоже были 2 кванта - запусти какую-нибудь пустышку сразу после первого.
    Я описал возможные причины возникновения в дополнении к своему предыдущему посту.

    З.Ы. Если ни у кого нет возражений, то я могу внести изменение в код планировщика. Если же Serge как обнаруживший причину, сам желает исправить, то не буду мешать.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • я против: это не баг.
    так лучше.
  • Who is online

    Users browsing this forum: Yandex [Bot] and 2 guests