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

Kernel architecture questions
  • Mario_r4
    Там это скорее всего задаётся программистом, как и алгоритм планировщика.

    Нам тоже понадобится планировщик, если увеличить квант до 20 - 50 мс.
    И ничто не мешает сделать несколько разных алгоритмов, на выбор программиста.
    Last edited by Serge on Wed May 15, 2013 12:44 am, edited 1 time in total.
  • art_zh wrote:Просое увеличение периода переключения задач ничего не даст.
    Почему ничего не даст? Сами же говорили с Сергеем про то как будут поделены проценты между соседями.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Serge wrote:Нам тоже понадобится планировщик, если увеличить квант до 20 - 50 мс.
    Давай пока не будем бросаться в крайности.
    1. Что решаем насчет "убрать DONT_SWITCH"?
    2. Нужно ли внедрение повышения частоты таймера в текущем виде?
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Потому что если таймер будет тикать слишком быстро - будут большие потери времени на обработку каждого IRQ,
    а если не слишком быстро - то проблема как была, так и останется:
    для тебя 200% у первого процесса - аццкая несправедливость, а кто-то скажет что и 110% зло.

    Ели уж решать, так принципиально:
    - каждое переключение задачи перезапускает интервальный таймер на новый квант,
    - неиспользованный квант сбрасывает таймер, переключает задачу и заново перезапускает таймер.
  • art_zh
    Идея неплоха, но тогда таймер сбивается и нафиг летят всякие wait_event_timeout(). То есть нужен отдельный таймер с блекджеком, например из LAPIC.
  • Serge
    - да.
    я тоже про LAPIC подумал. Этот точно не собьется.

    Mario
    1) можешь конечно убрать, но сдается мне что не пройдет и недели, как у кого-то где-то что-то невоспроизводимое выползет, и придется откатывать всё взад.
    2) было бы интересно поиграть с планировщиком на перепрограммируемом интервальном таймере, но на старых пнях и селеронах этот код точно не покатит.
    Last edited by art_zh on Wed May 15, 2013 1:15 am, edited 2 times in total.
  • Mario_r4
    1. Предлагаю убрать и посмотреть, что получится.
    2. Только с одновременным увеличением числа тиков в кванте. Ещё надо учесть, что всякие delay() cчитают 1тик = 0.01с
  • А еще если уж такая фича имеет место быть - надо довести ее до абсурда уровня полноценного приоритетного планировщика:

    - вместо сброса/установки единственного бита - проводить декремент содержимого DONT_SWITCH. чтобы прожорливые приложения могли запрашиавать (и по возможности получать) более высокий приоритет, не переключаясь (максимум) в течение 10 квантов.

    Скажем, сейчас FHT тратит на мегапиксельную картинку 400..440 миллисекунд. Если бы система могла в течение 5 квантов не переключать контекст и не ломала бы кэш, наверное можно было бы сократить время преобразования. Или хотя бы уменьшить разброс по времени.
  • art_zh wrote:А еще если уж такая фича имеет место быть - надо довести ее до абсурда уровня полноценного приоритетного планировщика:

    - вместо сброса/установки единственного бита - проводить декремент содержимого DONT_SWITCH. чтобы прожорливые приложения могли запрашиавать (и по возможности получать) более высокий приоритет, не переключаясь (максимум) в течение 10 квантов.
    1. Как ты видишь механизм запроса? Отдельная таблица, куда заносятся изменения в запросах приложений через специальную сисфункцию ядра?
    2. Боюсь такой механизм как минимум парализует графическую подсистему.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote: 1. Как ты видишь механизм запроса? Отдельная таблица, куда заносятся изменения в запросах приложений через специальную сисфункцию ядра?
    2. Боюсь такой механизм как минимум парализует графическую подсистему.
    1. можно через отдельную подфункцию 12-й, можно вообще вынести в заголовок KEX-файла нового формата (все еще грузимся со старым заголовком MINJET01, но ведь никто не запрещает продумать что-то свое, так?)

    2. Нет, графическая надсистема совершенно независима от планировщика.
  • Еще раз проверив все на реальной машине я внес изменение в SVN r. 3504.

    Запускал Gears вперемешку с Gmon на достаточно дохленьком RoverBook U800 и никаких эффектов квантовой физики и специальной теории относительности не наблюдал. Что не исключает их наличие, ибо человеческий глаз вкупе с мозгом инструмент не самый точный.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • art_zh wrote:2. Нет, графическая надсистема совершенно независима от планировщика.
    O RLY? Как насчет перемещения указателя курсора?
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario
    завтра специально придумаю какой-нибудь квантовый фифект. во славу релятивисткой физики.

    указатель мыши вроде только оконный стек перебирает емнип? ему длительность текущего процесса должна быть до фонаря.
  • art_zh wrote:указатель мыши вроде только оконный стек перебирает емнип? ему длительность текущего процесса должна быть до фонаря.
    Ты мыслишь не в том направлении. Вот двигает пользователь мышку, а курсор не двигается... а потом внезапно ПРЫГ на новую позицию! А все почему? Потому что велосипеду WARP двигатель приделали, драйвер мыши работает стабильно и меняет координаты, а MAIN LOOP терпеливо ждет когда FHT перестанет кошмарить планировщик задач... чтобы наконец нарисовать указатель в новой позиции.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Who is online

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