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

Kernel architecture questions
  • CleverMouse wrote:Это воровство. Если есть две ресурсоёмкие программы, то до r3504 вторая получала свои 10 мс каждые 30 мс, то есть за секунду работала 330 миллисекунд, сейчас она же получает свои 10 мс каждые 20 мс, то есть за ту же секунду работает 500 миллисекунд. Старая схема своровала 170 миллисекунд, как нетрудно вычислить.
    в реальной жизни или один обжора (ему по-любому 100% достанется), или много (тогда не важно, 3% у потока или 6% - все тормозят), или у кого-то должен быть приоритет.
    Никакого воровства: или одному хорошо, или всем (почти) одинаково плохо, или кто-то счастливчик.

    Но уж если уравниловка (в первый раз с начала века) вдруг стала так принципиальна - поставь пустышку перед вторым потоком, и все будет честно.
    jnc @f / inc edx = 73 01 42, adc edx, 0 = 83 D2 00. Откуда 2 байта?
    81 D2 00 00 00 00 - целых 3
    CleverMouse wrote:Чушь.
    Хамство.

    Гарантированное время кванта - это совершенно необходимое условие RTOS.
    (К сожалению, недостаточное. Но это вовсе не означает, что надо и его похерить)
  • в реальной жизни или один обжора (ему по-любому 100% достанется), или много (тогда не важно, 3% у потока или 6% - все тормозят), или у кого-то должен быть приоритет.
    Один обжора постоянно серьёзно чем-то занят, второй программе приспичило себя отрисовать - на некоторое время как раз две программы, занимающие столько, сколько дают.
    81 D2 00 00 00 00 - целых 3
    У тебя какой-то другой fasm?
    Гарантированное время кванта - это совершенно необходимое условие RTOS.
    Разумеется, нет. Время реакции - это совершенно необходимое условие RTOS, а оно улучшается в r3504 из-за сокращения цикла планировщика. Что не мешает ему оставаться ужасным, конечно.
    Сделаем мир лучше!
  • CleverMouse wrote: Один обжора постоянно серьёзно чем-то занят, второй программе приспичило себя отрисовать - на некоторое время как раз две программы, занимающие столько, сколько дают.
    Ага, вот когда спящему короткому потоку вдруг что-то приспичит отрисовать (а отрисовка займет меньше 10мс), или прочитать блок с диска/сети, или пообщаться с портами в/в...
    -- именно тогда этот воровской глюк и долбанет по обжоре.

    Еще раз: вариант Mario беспардонно крадет время у тех процессов, которым оно нужнее всего.
    У тебя какой-то другой fasm?
    Хм,
    действительно, fasm вставляет нулевой word вместо dword...
    3:3 в пользу Сержа.
    Гарантированное время кванта - это совершенно необходимое условие RTOS.
    Разумеется, нет. Время реакции - это совершенно необходимое условие RTOS, а оно улучшается в r3504 из-за сокращения цикла планировщика. Что не мешает ему оставаться ужасным, конечно.
    Насчет того, что более совершенно необходимо (при отсутствии всего остального) - здесь могут быть два разных мнения.
    Очень зависит от конкретной задачи.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh wrote:Mario
    Обещанный макет квантового дегенератора:
    Spoiler:

    Code: Select all

      
      use32             
      org    0         
      db     'MENUET01'  
      dd     1, START,  VOILA    
      dd     0x1000, 0x1000,  0,  0         
     
    START:
      rdtsc
      add eax, 1600000 ; = 1миллисекунда
      jnc @f
      inc edx
    @@:
      mov [keep_eax], eax
      mov [keep_edx], edx
    wait_1ms:
      rdtsc
      cmp edx, [keep_edx]
      jb wait_1ms
      cmp eax, [keep_eax]
      jb wait_1ms
    
      mov eax, 68
      mov ebx, 1
      int 40h
      jmp START   
    
    keep_eax  dd 0
    keep_edx  dd 0
    VOILA:
    
    отгрызает 1.6млн тактов (=1мс на моем проце) от текущего кванта

    т.е. в твоей версии планировщика - приватизирует (безвоздмездно!) время следующего "длинного" процесса.

    поставь время задержки 9миллисекунд, а потом запусти своего обжору.
    и шо, это таки-не багофича?
    Код не менял, т.е. "отгрызает 1.6млн тактов", поскольку Roverbook U800 имеет частоту около 498 МГц.

    Итак 3502 показывает следующую картину:
    3502.png
    3502.png (10.1 KiB)
    Viewed 7001 times
    А 3504 (специально не брал более новые версии сборок, чтобы сохранить чистоту эксперимента) уже показывает:
    3504.png
    3504.png (10.52 KiB)
    Viewed 7001 times
    Spoiler:Ожидаю прибытия Гордона Фримена.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • 1)Ты их зачем 3 шт понавесил? (последняя идет в зачет к первым двум)
    3 * 1.6М * 2.1нс = 9,7мс
    какая тут чистота эксперимента?

    2) На старом планировщике 1-й Example не может отъедать всего 2% - проверь версию ядра.
    Last edited by art_zh on Thu May 16, 2013 10:57 pm, edited 2 times in total.
  • art_zh wrote:Ты их зачем 3 шт понавесил? (последняя идет в зачет к первым двум)
    3 * 1.6М * 0.21нс = 9,7мс
    какая тут чистота эксперимента?
    Тогда описывай подробно последовательность - у меня навык телепатии плохо прокачан. :)
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • 1) проверь первое ядро: если там действительно 2% - значит это уже с твом планировщиком.

    2) убери последний дегенератор. двух достаточно перед первым обжорой, и одного - перед вторым

    3) можно повесить третьего обжору (для чистоты эксперимента) - сразу после второго, без дегенератора.
    Spoiler:предсказываю результат на старом ядре:
    d1, d2 - 6.4%
    e1 - 27.2%
    d3 - 6.4%
    e2 - 33.6%
    e3 - 20%

    на новом:
    d1, d2 - 10.6%
    e1 - 12%
    d3 - 10.6%
    e2 - 22.7%
    e3 - 33,3%
    Spoiler:Хотя этот твой пример еще нагляднее:
    2% - это всё что три революцонных хулигана оставили первому обжорке
    вместо законных 35% при старом режиме...
    Last edited by art_zh on Thu May 16, 2013 11:44 pm, edited 1 time in total.
  • Специально брал вновь распакованные из архивов ночные сборки, чтобы больше не ошибиться.
    3502.png
    3502.png (10.73 KiB)
    Viewed 6963 times
    3504.png
    3504.png (10.78 KiB)
    Viewed 6963 times
    Spoiler:
    art_zh wrote:2% - это всё что три революцонных хулигана оставили первому обжорке
    вместо 35% при старом режиме...
    Я считаю нельзя пускать революционеров в краснознаменный коммунистический лягушатник - они ведут себя как 15 летние оболтусы с детсадовсами, когда нет взрослых.
    Предложи решение для того, чтобы не было эффекта описанного в первых трех постах этой темы и я откажусь от ревизии 3504.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Поднять частоту таймера в два раза одновременно увеличить кол-во тиков в кванте. Картинка будет намного лучше.
  • Serge wrote:Поднять частоту таймера в два раза одновременно увеличить кол-во тиков в кванте. Картинка будет намного лучше.
    Может уж сразу в 10?
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4
    Для демок наверное лучше твой вариант: CleverMouse в чем-то права, цикл переключения задач действительно ускоряется. Хотя никто еще не знает к каким глюкам это может привести.

    Но для серьезных задач управления процессами и цифродробилок - ни за что!

    Serge
    Тогда и мышь на таймер?
  • Mario_r4
    10 для десктопа многовато будет, имхо 250 Гц самый оптимал.
    Закинь на фтп свой example, попробую один тест сделать.
  • art_zh
    Как дети малые. Знаешь же прекрасно, что для серьёзных задач нужен серьёзный планировщик. В упоминавшемся QNX было три (а может и больше, точно уже не помню) разных алгоритма планирования на выбор программиста.
  • Serge
    Закрути
    START: jmp START
    вот и весь example.
    Как дети малые. Знаешь же прекрасно, что для серьёзных задач нужен серьёзный планировщик.
    И так работает пока ничего другого нет - главное не ломать.
    Last edited by art_zh on Fri May 17, 2013 12:23 am, edited 2 times in total.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • Who is online

    Users browsing this forum: No registered users and 3 guests