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

Kernel architecture questions
  • art_zh wrote:я против: это не баг.
    так лучше.
    Просьба разжевать - чем лучше. Я не врубился в ход твоей мысли.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • а ты запусти перед первым обжорой несколько более активных процессов (например 5 GMON"ов с короткими периодами) - сам увидишь как сократится его квант по сравнению со вторым.

    в эмуляторах даже мышиная возня и перемещение окон даст требуемый фифект.
  • Я за изменение. Такое распределение квантов - баг. А если пытаться сделать из него фичу, получатся грабли, и кто-нибудь на них обязательно наступит.
    Mario_r4
    Раз у тебя уже протестировано - заливай.
  • art_zh
    Проблема решается повышением частоты таймера и увеличением числа тиков в кванте.

    ИМХО лучшим вариантом было бы увеличение кванта в 2-4 раза, и соответственно уменьшение накладных расходов на переключения контекста.
  • Блин, вы чо, перепились оба, что ли?

    Это же тогда реальный баг будет - первые пустышки будут отъедать время у последующего "длинного" процесса.

    И не важно какой период у кванта (его наоборот сокращать нужно, а не удлиннять) - всегда кто-то может съесть 99% времени и с чистой совестью отдать остаток на переключение.
  • art_zh
    Вот для этого и надо частоту таймера повышать и больше тиков в кванте. Если в кванте 10 тиков поток в худшем случае потеряет 1 тик - 10% времени.
  • Serge wrote:art_zh
    Проблема решается повышением частоты таймера и увеличением числа тиков в кванте.

    ИМХО лучшим вариантом было бы увеличение кванта в 2-4 раза, и соответственно уменьшение накладных расходов на переключения контекста.
    Помнится я такое уже предлагал на форуме и мне ЕМНИП ты же и возражал, что зачем 100500 раз вызывать шедулер и расходовать понапрасну ресурсы процессора.

    З.Ы. вот тут все происходило viewtopic.php?f=1&t=1307 и я извиняюсь - зря гнал, это мне Артем возражал viewtopic.php?f=1&t=1307&start=28
    Last edited by Mario_r4 on Wed May 15, 2013 12:23 am, edited 1 time in total.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Представьте, что перед обжорой сидит процесс (или несколько процессов), потребляющий 90% времени кванта (неважно, сколько тиков в кванте).
    Сейчас обжоре достается 110% времени. Это фича, с ней мы живем и здравствуем.

    А если убрать DONT_SWITCH - тогда 10%.
    И ничего поделать уже с этим будет нельзя, это будет реальный баг.
    Last edited by art_zh on Wed May 15, 2013 12:22 am, edited 1 time in total.
  • Mario_r4
    Сдаётся мне, ты не прав. Я писал примерно то же, что и выше. Увеличиваем частоту и кол-во тиков в кванте. То есть вызываем планировщик не каждый тик, а каждый второй, четвёртый, пятый или десятый, в зависимости от частоты таймера. Именно это я имел ввиду.
  • Serge wrote:Mario_r4
    Сдаётся мне, ты не прав. Я писал примерно то же, что и выше. Увеличиваем частоту и кол-во тиков в кванте. То есть вызываем планировщик не каждый тик, а каждый второй, четвёртый, пятый или десятый, в зависимости от частоты таймера. Именно это я имел ввиду.
    Я отписался в предыдущем посте - извиняюсь был не прав, это Артем возражал.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • art_zh
    Вот как раз важно, сколько тиков в кванте. Потому что между потоками всегда разделяется 1 тик. У на квант 1 тик и делится весь квант. Если квант 5 тиков делиться будет 0.2 кванта.

    Накладные расходы на вызов прерывания около 300 тактов. Не так и много.
  • ИМХО конечно, но лучше 100 или 1000 тиков на квант тогда, чтобы красиво и без потерь.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Сильно частоту задирать тоже не надо.
  • А сколько приходится на больших системах на квант тиков? Более всего меня интересует как с этим делом обстоит в QNX - это ведь хороший такой пример для подражания.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Who is online

    Users browsing this forum: No registered users and 2 guests