Сравнение планировщиков задач в линукс

популярная тема в последнее время

что, опять??

чего-то много об этом трепотни теперь

воткнули бы оба в ядро с возможностью выбора а мы бы и сравнили

>воткнули бы оба в ядро с возможностью выбора а мы бы и сравнили

плюсадин

независимое тестирование в реальных условиях )

Надо было сделать много планировщиков и дать возможность переключать их без перекомпиляции ядра. А мы потестируем...

/me думает перейти с 2.6.18 на 2.6.22...

> воткнули бы оба в ядро с возможностью выбора а мы бы и сравнили

Может всё-таки лучше один отличный планировщик чем несколько хороших? Зачем распылять силы на несколько планировщиков? Можно предвидеть аргумент "конкуренция", но ведь и так есть с кем соревноваться.

> IMHO лучше бы оставили возможность выбора нескольких планировщиков

Господи, идиоты, сколько же твердить, что не будет этого. Дятлы, читайте LKML, если своего ума не хватает догнать, почему два планировщика в ядре, делающих _одно и то же_ - это отвратительно.

P.S. Вообще, насколько я понял, идиоты, считающие, что должно быть два планировщика - делятся на два лагеря. Одни просто хотят, чтобы их было два, чтобы выбрать, а вторые так считают, потому, что в ядре несколько IO планировщиков. Вторые идиоты более опасны, т.к. даже примерно не понимают, что IO и CPU планировщики - это примерно как жопа и палец. Более того, все IO планировщики в ядре сделаны для _разных_ задач.

Это всё коварный план по уменьшению производительности ядра, а то становится неинтересно в раскладе, когда линупс рвёт всех без исключения.

Лучшее враг хорошего

А зачем менять планировщик, - кому нужна вторая венда?

У меня дежавю?

> P.S. Вообще, насколько я понял, идиоты, считающие, что должно быть два планировщика - делятся на два лагеря.

Рискуя попасть в лагеря для идиотов, все же спрошу:

А почему не может быть несколько планировщиков для разного типа задач/окружений? Где-то минимизовать латентность, а где-то максимизовать производительность?

Я понимаю, почему Линус не включил _одновременно_ и CSF, и SD - они в действительности решают одну и ту же задачу, а следовательно дублируют функции. Но что мешает, хотя бы на переходный период, оставить и старый O(1), и CSF мне все-таки непонятно.

Конечно, я не специалист в архитектуре ОС. Возможно, планировщик - настолько ключевая вещь, что "он должен быть только один". И все же - проясните свою точку зрения.

1) > CSF, и SD - они в действительности решают одну и ту же задачу

2) > Но что мешает, хотя бы на переходный период, оставить и старый O(1), и CSF мне все-таки непонятно

2 -> 1

Хорошо.

А можно их запустить одновременно и посмотреть - кто из них дальше и выше будет планировать?

А можно запустить старый под новым, а потом новый под старым и сравнить?

а вот интересно, когда додумаются сделать динамический приоритетинг процессов аля как в винде - то есть приложение с активным окном получает автоматический больший приоритет, при уходе в фон (закрывается другим окном) приоритет падает и т.д.. ИМХО для десктопного примениения линугза это был бы большой плюс.

> А можно их запустить одновременно и посмотреть - кто из них дальше и выше будет планировать?

У каждого планировщика свой механизм, каждый работает со своими структурами данных, со своим списком очередей, каждый делает одни и те же блокировки. Поэтому воткнуть два планировщика одновременно не получиться.

> А можно запустить старый под новым, а потом новый под старым и сравнить?

Планировщик - это не процесс, это кусок ядра.

>Господи, идиоты, сколько же твердить, что не будет этого. Дятлы, читайте LKML, если своего ума не хватает догнать, почему два планировщика в ядре, делающих _одно и то же_ - это отвратительно.

ну в ядре есть много дубляжа и что? кому надо ACPI юзает ACPI, а кому-то нужен APM и его юзает

никто не умир бы если бы можно было загрузить один или другой модуль

ничего отвратительного в этом нету

>вторые так считают, потому, что в ядре несколько IO планировщиков.

и почему бы планировщиков CPU не завести два?

>Планировщик - это не процесс, это кусок ядра.

и прекрасно

значит грузили бы кернел с параметром - именем планировщика (один бы выбрали по дефолту, другой по параметру)

_NET_WM_PID

Продублирую из соседней ветки (http://www.linux.org.ru/jump-message.jsp?msgid=2057601).

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

Дополнительно к тому:

(а) обнаруженные дефекты в одном из модулей не позволят выпустить очередную версию, прошедшую все тесты с включенным другим модулем. Что может сорвать сроки выпуска версий, а то и вовсе поставить крест (при отсутствии поддержки одного из модулей) на дальнейшем развитие проекта (без серьезных потрясений);

(б) функциональное тестирование собственно модулей существенно усложняется, ибо все обнаруженные в одном модуле дефекты могут проявляться, а могут и не проявляться (в зависимости от многих факторов) в другом модуле. Что приводит к необходимости создания специальной группы, занимающейся портированием функциональных тестов между модулями;

[offtopic]

(в) "внутренняя" конкуренция не всегда зер гутт. Ref. история проектов Macintosh и Lisa в фирме Apple;

[/offtopic]

Но и преимущества, очевидно, у такого подхода (два альтернативных модуля в одном проекте) тоже есть. Например, возможность дополнительной оптимизации ПО под конкретные задачи.

IMHO, все-таки лучше в таком случае выбирать один модуль. И не обязательно основываясь только на технических характеристиках. Вопросы, связанные с прогнозом надежности поддержки и развития проекта тут тоже не последнюю роль играют.

>два планировщика в ядре, делающих _одно и то же_ - это отвратительно.

Отвратительнее золотого дождя?

Смотрим таблицы. У нового планировщика везеде лучшие показатели при работе в иксах. Одного этого уже достаточно, чтобы считать его лучшим выбором для десктопов.

С другой стороны - он сильно страдает при сильной загрузке - см. таблицу video. С точки зрения пользователя, опять же, сам видеофрагмент, по видимому, будет проигрывать без проседания, просядет все остальное.

Вывод - новый планировщик ориентирован на десктопное применение Linux.

ИМХО Линус не хочет сделать выбор планировщиков при компиляци ядра из-за нелюбви к автору одного из них. Это очень печально, но опять же ИМХО человек взявшийся быть лидером имеет право на такие причуды, хоть они и не делают ему чести.:-(

> Отвратительнее золотого дождя?

Золотой дождь - это прекрасно! :)

Давно пора. Хорошо бы вообще без перезагрузки. Даешь микроядро!

> Таблицы с результатами .

Честно говоря, ничерта не понял из этих таблиц.

>Может всё-таки лучше один отличный планировщик

А такой бывает?

>а вот интересно, когда додумаются сделать динамический приоритетинг процессов аля как в винде - то есть приложение с активным окном получает автоматический больший приоритет, при уходе в фон (закрывается другим окном) приоритет падает и т.д.. ИМХО для десктопного примениения линугза это был бы большой плюс.

это было бы здорово, однако не все так просто. в линаксе для непривелегированного пользователя есть только только одна возможность изменять приоритет процесса (потока) - уменьшать его (nice, setpriority). [для особо одаренных - речь о приоритете, а не о его численном значении.] например в соляре для этого есть свой специальный scheduling class - класс интерактивных процессов, приоритет которых (в определенном назначенном диапазоне) может быть изменен (в любую сторону) непревилигированным пользователем. таким образом в соляре, соляровский vm ведет себя именно так, как ведет себя видовоз, назначая процессам, окно которых получает фокус, повышенный приоритет.

для линакса такого поведения несомненно можно добиться, но можно и гланды через жопу вырезать... автогеном.

интересное обсуждение есть здесь http://jeffr-tech.livejournal.com/12933.html

мне кажется что вот это замечание джефа должно заставить кое кого задуматься ...

<quote> 15-20 cache misses to schedule a thread is pretty significant. I can't say whether it will show up on profiles or not but I suspect so given my experience with similar tree datastructures in the VM. Consider that with the ULE queue you'll get somewhere around 3 cache misses </quote>

все знают что cache misses - это препротивнейшая штука, и то что в CFS этих тормозов на порядок больше чем в ULE очень хреново для CFS.

<quote> According to ingo himself having 1,000 runnable tasks increases context switch cost by 20%.. That's a 10 deep tree. At worst you'd expect another 5 levels in the tree, so 30% total. It's not killing you but it's not ideal either. </quote>

Чёта много внимания в новостях на LOR стало уделяться планировщику. Сообщение от Пиотровски я читал безо всяких наводок opennet, посмотрел результаты и... никакого вывода не сделал. Сначала надо подождать что скажет Ingo, поскольку я так до конца и не понял что за нагрузка была, может очередное тестирование sched_yeld?

По поводу "много планировщиков хороших и разных". Разработчики AS, Deadline и CFQ солидарны в том, что в своё время была сделана ошибка в процессе разработки, и по хорошему, надо было оставить только один планировщик.

> Разработчики AS, Deadline и CFQ солидарны в том, что в своё время была сделана ошибка в процессе разработки, и по хорошему, надо было оставить только один планировщик.

И что ж они до сих пор не разродились на один, который заменит эти все три?

Странные люди....

Ну ведь очевидно, что для разного типа задач нужны разные планировщики. Для десктопа - отдавать бОльший приоритет задаче с активным окном. Для вебсервера - честно делить CPU между процессами, для сервера СУБД - отдать гарантированный процент для того же Оракела и оставить гарантированный процент времени CPU для всех остальных сервисов.

Я не могу понять, это так сложно для понимания, или Линукс у нас теперь мегаэнтерпрайзен и менее чем на мейнфреймах работать не должен? Задачи - разные, значит, разные планировщики.

Да, тяжело поддерживать несколько планировщиков одновременно. Но и Линукс уже не игрушка, пора взрослеть, если хочется быть востребованным не только для решения узкого круга задач.

>Что может сорвать сроки выпуска версий, а то и вовсе поставить крест (при отсутствии поддержки одного из модулей) на дальнейшем развитие проекта (без серьезных потрясений);

с этим я согласен, однако я думаю на этот счет следующее:

в данный момент имеется две команды разрабатывающие два планировщика. и обе вроде бы горят желанием дальше работать и главное, работают.

если в будущем ситуация изменится так что какая-то забьет на работу и будет затягивать другие, почему бы в будущем не выкинуть один из?

>Включение двух модулей, предназначенных для выполнения одной и той же задачи, увеличивает сложность интегрального тестирования продукта с большой точностью в два раза

интегрально отнюдь не в два раза. в ядре много чего дублируется и ничего это один из компонентов всего. да важный, но один из

>(в) "внутренняя" конкуренция не всегда зер гутт.

насколько я понимаю ситуацию она уже дефакто есть.

>IMHO, все-таки лучше в таком случае выбирать один модуль.

а мое имхо что лучше два. и один из них включенный по дефолту, другой опциональный :)

>Для десктопа - отдавать бОльший приоритет задаче с активным окном.

планировщик здесь непричем. мне кажется подход, реализованный в винде и соляре - оптимален.

>Для вебсервера - честно делить CPU между процессами, для сервера СУБД - отдать гарантированный процент для того же Оракела и оставить гарантированный процент времени CPU для всех остальных сервисов.

задачи типа: вот этим 3 процессам дать 20% cpu, вот этим 10-ти - 30%, a а остальное честно поделить между оставшимися - решается групповыми политиками или подобными механизмами ( как например в соляре )

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

> ИМХО Линус не хочет сделать выбор планировщиков при компиляци ядра из-за нелюбви к автору одного из них. Это очень печально, но опять же ИМХО человек взявшийся быть лидером имеет право на такие причуды, хоть они и не делают ему чести.:-(

а я Линусу доверяю в выборе полностью, у него картинка состояния дел и возможностей намного полнее чем у любого из нас. Для меня на самом деле давно удивительно как один планировщик умудряется неплохо (я не говорю идеально!) работать в самых разных ситуациях, на разном железе. Ну нельзя сделать идеально для всех, поэтому во всех серьёзных проектах выбирается золотая середина, когда всем не слишком хорошо, но и не слишком плохо. Давно жду, когда кернел-девелоперы скажут: всё, приехали, пора планировщик делать по-разному под разные условия, потому что в некоторых ситуациях проигрыш от дженерик-подхода слишком большой. Как всегда подталкивает в немалой степени железо, думаю доживём до времени когда Саныч скажет что-нибудь вроде: ну пля, пицуки стали как big iron, цпу/шины назначаются/делятся между юзерами/процессами как деньрожденский торт на столе моей знакомой секретарши.

Дык интерактивные (IO-ориентированные) итак получают больший приоритет. Не пойму, чего вы еще от него хотите? Большего начального приоритета? Но это уже задача не планировщика, и, вероятно, даже не ОС. Пишите оконный манагер, который будет самостоятельнол приоритеты процессов дергать при переключении окон. Или я где-то не прав? :?

> По поводу "много планировщиков хороших и разных". Разработчики AS, Deadline и CFQ солидарны в том, что в своё время была сделана ошибка в процессе разработки, и по хорошему, надо было оставить только один планировщик.

Изначально было ясно, что единое комьюнити и уменьшение спектра программ - это великий плюс и общая задача, всяко лучше решаемая в отличие от нынешнего зоопарка и велисипедостроения, что лишь откалывает разработчиков и приводит к раскладу "лучше быть начальником канализации с Усть-Пердинске, чем простым инженером, скажем, в Париже".

> > Разработчики AS, Deadline и CFQ солидарны в том, что в своё время была сделана ошибка в процессе разработки, и по хорошему, надо было оставить только один планировщик.

> И что ж они до сих пор не разродились на один, который заменит эти все три?

CFQ, ага?

>задачи типа: вот этим 3 процессам дать 20% cpu, вот этим 10-ти - 30%, a а остальное честно поделить между оставшимися - решается групповыми политиками или подобными механизмами ( как например в соляре )

Чем приоритеты не угодили? Менее удобно, возможно.

> Ну ведь очевидно, что для разного типа задач нужны разные планировщики. Для десктопа - отдавать бОльший приоритет задаче с активным окном. Для вебсервера - честно делить CPU между процессами, для сервера СУБД - отдать гарантированный процент для того же Оракела и оставить гарантированный процент времени CPU для всех остальных сервисов.

Ландау и Лившиц хоть доказывали большую часть и лишь изредка писали "очевидно", а Ваше доказательство таки где? Так тяжко понять, что шедулер может быть один, но в различных режимах работать по разным паттернам, но по одному и тому же алгоритму?

Отдача же приоритета "активному окну" - полная херня и вендавозные бредни, откуда планировщик знает о такой абстракции как "окно"? Вычислительной мощносит современной техники же (и техники 3-4 летней давности - тоже и вполне себе) хватит любым "окнам", а ежели приложение требует могучих вычислений типа рендеринга или кодирования видео, то окна становятся пофиг, ибо это всё занимает не секунду и не две - а часы и сутки.

> для сервера СУБД - отдать гарантированный процент для того же Оракела и оставить гарантированный процент времени CPU для всех остальных сервисов.

Это что ещё за оракеловый сервер СУБД такой, на котором ещё и "другие сервисы" крутятся?

поставил себе CFS - пока не жалуюсь. но у этого планировщика есть одна проблема, о которой говорил(http://jeffr-tech.livejournal.com/12933.html#cutid1) Jeff Roberson(создатель BSD'шного ULE) - cfs не O(1) планировщик - это раз, cfs использует rb-tree для хранения процессов и при большом кл-ве процессов (>= 1000), он будет работать на 20% медленнее.

+ в коментах Jeff обещал сравнить CFS и ULE. я вот с нетерпением жду результатов =)

>Ландау и Лившиц хоть доказывали большую часть и лишь изредка писали "очевидно", а Ваше доказательство таки где?

Мне - очевидно. Если я работаю на десктопе, то активное окно у меня _не_должно_тормозить_. Пусть даже при этом все остальное работает медленнее. Потому, что в данный момент я работаю с _активным_ окном, а не с кучей фоновых приложений.

>Так тяжко понять, что шедулер может быть один, но в различных режимах работать по разным паттернам, но по одному и тому же алгоритму?

Тяжко до чрезвычайности. Почему вдруг задачи, решаемые на Линуксе - разные, вплоть до диаметрально противоположных, а планировщик для мейнфрейма с 1024 процессорами и числодробительной задачей, и рабочей станции с просмотром видео и фоновым качанием битторента - один и тот же? Чудес не бывает, увы. Нельзя одни и тем же ножом резать колбасу дома и проводить операции в больнице.

>Отдача же приоритета "активному окну" - полная херня и вендавозные бредни,

Конечно-конечно. Бредни это, разумеется. Ровно до того момента, пока на десктоп в массовом режиме не начнут ставить Линукс.

>откуда планировщик знает о такой абстракции как "окно"?

Узнает - через syscall из оконного менеджера, очевидно. Нечто вроде void set_shed_priority(pid_t pid, priority_t priority);

>Вычислительной мощносит современной техники

О, я понял. Пойдем по пути Windows Vista?

>же (и техники 3-4 летней давности - тоже и вполне себе) хватит любым "окнам"

Вранье. 4 года назад был 2003 год. Четвертый пень 2.0 ГГц был дорогой топовой моделью. Народ же, в массе своей, сидел на третьих пеньках.

>а ежели приложение требует могучих вычислений типа рендеринга или кодирования видео, то окна становятся пофиг, ибо это всё занимает не секунду и не две - а часы и сутки.

Причем тут рендеринг? Я хочу, чтобы процесс с _активным_ окном в Xorg на моем Дебиане на PIII-800/768 не тормозил. Мне это надо для того, чтобы _визуально_ система работала _быстро_.

>Это что ещё за оракеловый сервер СУБД такой, на котором ещё и "другие сервисы" крутятся?

Элементарно, Ватсон! "Другие сервисы" - это snmpd и sshd. Так вот, я хочу, чтобы им _всегда_ было выделено, например 0.03% CPU. Для чего? Для того, чтобы когда я вошел на нагруженную систему, я мог без тормозов: а) снять статистику посредством snmp б) сделать необходимые действия в консоли.

Прошу прощения, что вмешиваюсь в ваш спор (хотя... сама форма ведения дискуссии в публичных конференциях в Internet это подразумевает;)).

> Отдача же приоритета "активному окну" - полная херня и вендавозные бредни...

А вот тут я с Вами не могу в полной мере согласиться. IMHO, у desktop'ной ОС нет и не может быть более важной задачи, нежели работать в диалоговом режиме, сиречь --- адекватно реагировать на *команды* пользователя (например, на движения манипулятора мышь или клавиатурный ввод). Linux же сейчас такой отзывчивостью отнюдь не отличается.

Например, на машине, с которой я сейчас пишу этот пост (i865G, iP-IV 2.8GHz, 512MB), регулярно случаются "подвисания" (отсутствие видимой реакции на действия пользователя).

Для справки, WinXP (пока стояла) на этой же самой машине ни разу такого не допускала (курсор мышка всегда гоняла, при условии уже полученного фокуса окном ввода текст вводился и отображался почти без задержки, всегда, даже когда рамка окна отрисовывалась больше минуты). Сравнение тут, очевидно, отнюдь не в пользу Linux.

Для серверной ОС согласен, этот параметр (отзывчивость) не является важным. А вот для десктопной --- более чем.

> 2 -> 1

Бред. Запусти три процесса на двух ядрах и посмотри как эти планировщики(O(1) и CFS) top-ом делают одно и тоже.

> Включение двух модулей, предназначенных для выполнения одной и той же задачи, увеличивает сложность интегрального тестирования продукта с большой точностью в два раза (ибо все тестовые сценарии придется прогонять с обоими модулями).

Какой ужас! На основании всего чт там написано срочно нужно выкинуть из ядра поддержку SMB, CIFS, Coda, XFS, JFS, Reiser и всего эксмпериментального кода. Оставляем ext3 и NFS.

> Мне - очевидно. Если я работаю на десктопе, то активное окно у меня _не_должно_тормозить_. Пусть даже при этом все остальное работает медленнее. Потому, что в данный момент я работаю с _активным_ окном, а не с кучей фоновых приложений.

Ну так и вставь ему приоритет побольше, при чём тут тепепатические возможности шедулера?

> Тяжко до чрезвычайности. Почему вдруг задачи, решаемые на Линуксе - разные, вплоть до диаметрально противоположных, а планировщик для мейнфрейма с 1024 процессорами и числодробительной задачей, и рабочей станции с просмотром видео и фоновым качанием битторента - один и тот же? Чудес не бывает, увы. Нельзя одни и тем же ножом резать колбасу дома и проводить операции в больнице.

Так мы о десктопах говорим, или о рынке мейнфреймов? На втором рулят серьёзные системы и линупс туда суётся чрезвычайно редко, не тот класс задач и не та система.

> Конечно-конечно. Бредни это, разумеется. Ровно до того момента, пока на десктоп в массовом режиме не начнут ставить Линукс.

Его ___уже___ ставят, об Убунту и новых контрактах слышали? Или редхетовые и зюзевые корпоративные десктопы - нишевые решения, занимающие менее 0.1% рынка в самом лучшем случае?

> Узнает - через syscall из оконного менеджера, очевидно. Нечто вроде void set_shed_priority(pid_t pid, priority_t priority);

Ну например. Пошлите соответствующий патч разработчику WM.

> О, я понял. Пойдем по пути Windows Vista?

Нет, не пойдём. Почему не пойдём? Потому что всё и так хорошо, а Вы предлагаете городить костыли, лишь бы на железе столетней давности окошки чуток поотзывчивей были, и под влиянием похожих товарищей в ядро пропихавются откровенно провальные на первый взгляд (а следовательно требущие долгой доводки) патчи к очень глобальным вещам.

> Вранье. 4 года назад был 2003 год. Четвертый пень 2.0 ГГц был дорогой топовой моделью. Народ же, в массе своей, сидел на третьих пеньках.

И правильно делал, потому как p4-1.8 откровенно сливал p3-1.2. И __тогдашний__ линукс вовсе не тормозил на таком железе, как сегодня не тормозит на сегодняшнем. И были специально воткнуты preemption-патчи, специльано для такох вот требовательных и не понимающих сути вещей, но видать и этого мало? Воткнём иксы в едро? Кеды туда же? Лишь бы окошки не тормозили? А что реальным задачам будет отдаваться меньше ресурсов - дык пофиг?

> Причем тут рендеринг? Я хочу, чтобы процесс с _активным_ окном в Xorg на моем Дебиане на PIII-800/768 не тормозил. Мне это надо для того, чтобы _визуально_ система работала _быстро_.

Это да, на таком железе о рендеринге речь уже не идёт... слаку 8.0 пробовал использовать? Аль нужен наикрутейший федора-коре прям с момента вставки установочного DVD осыпающийся в корку, зато с берилом и официальными требованиями уровня ____Pentium 4____ (и соответствующей памяти, ага)?

> Элементарно, Ватсон! "Другие сервисы" - это snmpd и sshd. Так вот, я хочу, чтобы им _всегда_ было выделено, например 0.03% CPU. Для чего? Для того, чтобы когда я вошел на нагруженную систему, я мог без тормозов: а) снять статистику посредством snmp б) сделать необходимые действия в консоли.

О каждой транзакции отдельное мыло на сервак статистики высылается с подробным описанием и отладочной информацией об ооной? Ну дождись тиклесс-подсистемы и выставь интервал соответствующий, пополам с патчами для реалтайма от Молнара. Приоритеты тоже, видимо, не рулят, ага, равно как необходимость конфигурирования возникает раз в 5 секунд...

Дядя, ты апгрейд сделал бы чтоль, дабы мы тут не вспоминали Саныча, Мишу и коварные двери, призывая запатчить ядро вусмерть и оптимизировать всё и вся, краем глаза офигевая от числа нулей и времени потребных.

> Какой ужас! На основании всего чт там написано срочно нужно выкинуть из ядра поддержку SMB, CIFS, Coda, XFS, JFS, Reiser и всего эксмпериментального кода. Оставляем ext3 и NFS.

<Тут должны были быть рациональные обоснования неправоты>. Убей себя.

> Прошу прощения, что вмешиваюсь в ваш спор (хотя... сама форма ведения дискуссии в публичных конференциях в Internet это подразумевает;)).

Да пофиг, вежливостью я никогда не отличался, кроме как в обществе женщин и совсем маленьких детей (подростки ещё и покруче могут) ;)

> А вот тут я с Вами не могу в полной мере согласиться. IMHO, у desktop'ной ОС нет и не может быть более важной задачи, нежели работать в диалоговом режиме, сиречь --- адекватно реагировать на *команды* пользователя (например, на движения манипулятора мышь или клавиатурный ввод). Linux же сейчас такой отзывчивостью отнюдь не отличается.

HZ=1000 (100000), тиклесс, преемптибля. Эта вся фигня уже даже в серверные ядра включается с какого-то фига, когда вроде как прямой задачей оных является максимальная производительность при сохранении полной стабильности и отсутствии лишнего.

> Например, на машине, с которой я сейчас пишу этот пост (i865G, iP-IV 2.8GHz, 512MB), регулярно случаются "подвисания" (отсутствие видимой реакции на действия пользователя).

Процессор не перегревается? Берил не запущен? Я вот когда в гостях всяких бываю и смотрю на венду, что стоит на тогдашнем самом распространённом железе (p4/2.4-3.0 + 512M) - она точно так же время от времени дёргается и подвисает, тогда как уменя сиих траблов не наблюдает ещё со времён последних p3 (ядер 2.4 без всякого preemption, 100-герцовых и вроде как не очень отзывчивых, ага). Может карма или чего в консерватории подправить?

> Для справки, WinXP (пока стояла) на этой же самой машине ни разу такого не допускала (курсор мышка всегда гоняла, при условии уже полученного фокуса окном ввода текст вводился и отображался почти без задержки, всегда, даже когда рамка окна отрисовывалась больше минуты). Сравнение тут, очевидно, отнюдь не в пользу Linux.

Антивирус поставьте. К слову о процессорных шедулерах - они тут не при чём, достаточно мощи, а вот дисковые - могут и быть виноваты, CFS именно для этого придумали.

> Для серверной ОС согласен, этот параметр (отзывчивость) не является важным. А вот для десктопной --- более чем.

Всё решаемо, нужно лишь чуток ручек приложить и без всяких патчей в ядро ;)

> <Тут должны были быть рациональные обоснования неправоты>.

Но пока я их не вижу. А вот Reiser,XFS и JFS делают тоже самое что и etx3, значит их из-за квадратичной сложности поддержки нужно исключить.

> Убей себя.

Умри ничтожество! :)

> Всё решаемо, нужно лишь чуток ручек приложить и без всяких патчей в ядро ;)

Верю. Вот только есть пара соображений: (а) я не буду тратить на это время, ибо все равно системя "я + ПЭВМ" работает не быстрей, чем самый медленный элемент системы. В этой системе медленным элементом являюсь я:) А к "микроподвисаниям" секунды на две--три (максимум, по ощущениям, чуть больше пяти) я уже привык. Да и квалификация моя не позволяет лазить больше определенного по /etc; (б) под MS Windows моя квалификация тоже не позволяла мне лазить по реестру дальше, чем необходимо. Но там таких тормозов не было никогда. Я из этого сделал может быть, не совсем (а то и совсем не) верный вывод о "тяжком наследии серверного прошлого".

P.S. Ничего лишнего никогда не запускал. Так что не в том дело. Да и надо-то мне: браузер (Opera), mail-клиент, командная строка, текстовый редактор (vim) да компилятор с отладчиком. И LaTeX с DVI/PS-preview'ером, конечно. А антивирус... с msblast'а ни одного вируса не видел вживую, хоть антивирусов никогда на машине не держал. IMHO, культура использования программно-аппаратных комплексов и хорошо настроенный firewall гораздо эффективней для.