Board.KolibriOS.org

art_zh wrote:А если без [DONT_SWITCH] - тогда тоже как-то нечестно получается, ведь от предыдущего кванта уже отгрызли несколько кусочков.

Я проверил на реальной машине - без проверки [DONT_SWITCH] все распределяется равноправно. Запускал 5 протоков-обжор.

art_zh wrote:я против: это не баг.
так лучше.

Просьба разжевать - чем лучше. Я не врубился в ход твоей мысли.

а ты запусти перед первым обжорой несколько более активных процессов (например 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

Представьте, что перед обжорой сидит процесс (или несколько процессов), потребляющий 90% времени кванта (неважно, сколько тиков в кванте).
Сейчас обжоре достается 110% времени. Это фича, с ней мы живем и здравствуем.

А если убрать DONT_SWITCH - тогда 10%.
И ничего поделать уже с этим будет нельзя, это будет реальный баг.

Mario_r4
Сдаётся мне, ты не прав. Я писал примерно то же, что и выше. Увеличиваем частоту и кол-во тиков в кванте. То есть вызываем планировщик не каждый тик, а каждый второй, четвёртый, пятый или десятый, в зависимости от частоты таймера. Именно это я имел ввиду.

Serge wrote:Mario_r4
Сдаётся мне, ты не прав. Я писал примерно то же, что и выше. Увеличиваем частоту и кол-во тиков в кванте. То есть вызываем планировщик не каждый тик, а каждый второй, четвёртый, пятый или десятый, в зависимости от частоты таймера. Именно это я имел ввиду.

Я отписался в предыдущем посте - извиняюсь был не прав, это Артем возражал.

art_zh
Вот как раз важно, сколько тиков в кванте. Потому что между потоками всегда разделяется 1 тик. У на квант 1 тик и делится весь квант. Если квант 5 тиков делиться будет 0.2 кванта.

Накладные расходы на вызов прерывания около 300 тактов. Не так и много.

ИМХО конечно, но лучше 100 или 1000 тиков на квант тогда, чтобы красиво и без потерь.

Сильно частоту задирать тоже не надо.

А сколько приходится на больших системах на квант тиков? Более всего меня интересует как с этим делом обстоит в QNX - это ведь хороший такой пример для подражания.