Понижения времени отклика Linux

Вот включил себе на 2.5 и то и другое. Прикольно получилось. Но не знаю.... Вот это вытесняемое ядро... Ситуация такая например когда грузится мозилла то музыка может "тянуть". С 2.4 такого не было. Конечно достигается какой-то выигрыш на нажимании кнопок и отклике прог на эти нажимания но ценой забивания чего-то другого. А как же приорити?
Это конечно фичи не для сервера а для десктопа и то я не уверен что все хотят такие фичи на десктопе. Но пусть будут посмотрим как будет развиваться.

Эти фичи ни для десктопа, ни тем более для сервера :)) Это для встраиваемых и промышленных устройств. Типа, конкуренция QNX. :))

2vitamin (*) (2002-03-22 14:38:44.0):
> Это для встраиваемых и промышленных устройств.
Ну почему? Про MontaVista'вский патч я согласен, он для realtime,
а патч от Ingo - вполне, он просто reschedule чаще делает...

А чем low-latecy не для сервера? Я ничего не утверждаю, я просто хочу послушать умных людей. :) Про вытеснение - тут не так давно монго чего наговорили. А почему IM патч для сервера нехорошо?

Там прикол. Эти патчи друг без друга приводят к ухудшению характеритик работы ядра через 12 часов работы :)

>А чем low-latecy не для сервера?
Потому что достигается за счет снижения производительности. На десктопе тебе, типа,
все равно - 99% времени процессор простаивает.

> Про вытеснение - тут не так давно монго чего наговорили. А почему IM патч для
> сервера нехорошо?
Дык в разговоре про "вытеснение" и обсуждался этот патч :)

> Потому что достигается за счет снижения производительности.

Смотря для каких задач. Для вебсервера снижение времени отклика очень хорошо.

Насколько я понимаю это preemble патч типо real-time отклик достигается за счет общего понижения производительности а патч от Ingo производительность типо наоборот не понижает при scheduling'е процессов.

2anonymous (*) (2002-03-22 18:04:33.0):
> Смотря для каких задач.
Ессно

> Для вебсервера снижение времени отклика очень хорошо.
Распространенное заблуждение.

1. В Сети валяется много исследований на данную тему - основную долю
в latency приходится на сеть, задержки на старт процессов всегда пренебрежимы;
2. Уж если сервер начал тормозить, то, очевидно, ему именно производительности
не хватает.

anonymous (*) (2002-03-22 16:39:52.0)

Это не прикол. Просто low latency закрывает не все ветки - так и должно быть. preemt же работает как танк - способ грубой силы так сказать, но он судя по всему должен жрать больше ресурсов - так как работает не когда надо а всегда .

> Уж если сервер начал тормозить, то, очевидно, ему именно производительности

Распространенное заблуждение ;) Пойми, подразумевается, что сервер не перегружен,
и сравнение идет как говорится "при прочих равных условиях".

Только хотел написать мысль, как вижу, Die-Hard ее уж выдал :)
Молодцом!

to последний анонимус:
>и сравнение идет как говорится "при прочих равных условиях"
А ты призадумайся, из каких составных частей происходит время
ответа сервера? Какова в нем доля этой самой задержки за счет
перепланировщика? Ответ: совершенно незначима при любых условиях.

Немножко не в тему, но : Господа, а никто не пытался писать mpeg4 на линуксе с /dev/video в real-time ? Какая комбинация патчей решает проблему с нелинейным ходом времени ? Или это из-за железа ?

> никто не пытался писать mpeg4 на линуксе с /dev/video в real-time

Я писал. Прекрасно поучается. Все зависит конечно от качества записи (битрэйт, цвет и т.д.).
Обычное ядро 2.4.18.

> А ты призадумайся, из каких составных частей происходит время

Мне плевать, честно говоря. Нет я конечно представляю, но чем теории строить,
возьми лучше apachebench и заряди его на линуксе и на *bsd. Он покажет тебе
среднее и максимальное время отклика без лишних умозаключений ;)

А нафиг оно нуна - шоб било так , как в винде - что юзаешь - то и всю систему жрёт??????????