Я проверил на реальной машине - без проверки [DONT_SWITCH] все распределяется равноправно. Запускал 5 протоков-обжор.art_zh wrote:А если без [DONT_SWITCH] - тогда тоже как-то нечестно получается, ведь от предыдущего кванта уже отгрызли несколько кусочков.
Работа планировщика задач
-
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Просьба разжевать - чем лучше. Я не врубился в ход твоей мысли.art_zh wrote:я против: это не баг.
так лучше.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
а ты запусти перед первым обжорой несколько более активных процессов (например 5 GMON"ов с короткими периодами) - сам увидишь как сократится его квант по сравнению со вторым.
в эмуляторах даже мышиная возня и перемещение окон даст требуемый фифект.
в эмуляторах даже мышиная возня и перемещение окон даст требуемый фифект.
Я за изменение. Такое распределение квантов - баг. А если пытаться сделать из него фичу, получатся грабли, и кто-нибудь на них обязательно наступит.
Mario_r4
Раз у тебя уже протестировано - заливай.
Mario_r4
Раз у тебя уже протестировано - заливай.
art_zh
Проблема решается повышением частоты таймера и увеличением числа тиков в кванте.
ИМХО лучшим вариантом было бы увеличение кванта в 2-4 раза, и соответственно уменьшение накладных расходов на переключения контекста.
Проблема решается повышением частоты таймера и увеличением числа тиков в кванте.
ИМХО лучшим вариантом было бы увеличение кванта в 2-4 раза, и соответственно уменьшение накладных расходов на переключения контекста.
Блин, вы чо, перепились оба, что ли?
Это же тогда реальный баг будет - первые пустышки будут отъедать время у последующего "длинного" процесса.
И не важно какой период у кванта (его наоборот сокращать нужно, а не удлиннять) - всегда кто-то может съесть 99% времени и с чистой совестью отдать остаток на переключение.
Это же тогда реальный баг будет - первые пустышки будут отъедать время у последующего "длинного" процесса.
И не важно какой период у кванта (его наоборот сокращать нужно, а не удлиннять) - всегда кто-то может съесть 99% времени и с чистой совестью отдать остаток на переключение.
art_zh
Вот для этого и надо частоту таймера повышать и больше тиков в кванте. Если в кванте 10 тиков поток в худшем случае потеряет 1 тик - 10% времени.
Вот для этого и надо частоту таймера повышать и больше тиков в кванте. Если в кванте 10 тиков поток в худшем случае потеряет 1 тик - 10% времени.
Помнится я такое уже предлагал на форуме и мне ЕМНИП ты же и возражал, что зачем 100500 раз вызывать шедулер и расходовать понапрасну ресурсы процессора.Serge wrote:art_zh
Проблема решается повышением частоты таймера и увеличением числа тиков в кванте.
ИМХО лучшим вариантом было бы увеличение кванта в 2-4 раза, и соответственно уменьшение накладных расходов на переключения контекста.
З.Ы. вот тут все происходило 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%.
И ничего поделать уже с этим будет нельзя, это будет реальный баг.
Сейчас обжоре достается 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 тактов. Не так и много.
Вот как раз важно, сколько тиков в кванте. Потому что между потоками всегда разделяется 1 тик. У на квант 1 тик и делится весь квант. Если квант 5 тиков делиться будет 0.2 кванта.
Накладные расходы на вызов прерывания около 300 тактов. Не так и много.
ИМХО конечно, но лучше 100 или 1000 тиков на квант тогда, чтобы красиво и без потерь.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Сильно частоту задирать тоже не надо.
А сколько приходится на больших системах на квант тиков? Более всего меня интересует как с этим делом обстоит в QNX - это ведь хороший такой пример для подражания.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Who is online
Users browsing this forum: No registered users and 1 guest