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

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

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

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

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

Ахахах. Клоун! Так и вижу дружественный Linux Ubuntu или SuSe: юзер запускает окно затем запускает консоль, делает sudo renice -10 `pidof {прога}` затем при смене активного окна снова идет в консоль. делает renice 0 `pidof прога`; renice -10 `pidof прога2` =)))))))))

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

Linux это и есть серьезная система, а твоя умирающая сопляра, которую ты тут пеаришь - тормозная распальцованная фигня с энтырпрайз дырами.

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

Про солярку не знаю, а вот виндовый планировшик хорошо масштабируется только до 2 процессоров/ядер, далее идет завал производительности (поправили ли это в висте -- не знаю)

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

Они заточены под свои задачи, двоечник.

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

Зловещие мертвецы, блин, даже помереть нормально не могут, сразу в зомби морфятся и пока не перегрузишься - не отвалятся...

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

Фигасе "микро", тут если в 0.5 секунды рывок возникает - уже

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

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

это Вас память подводит. Я в конце 2003 купил себе уже P4 C 2.4 (Nortwood, шина 800), который прекрасно разогнался до 3 на матери ASUS P4P800, а в продаже уже были 3.0Hz

> Верю. Вот только есть пара соображений: (а) я не буду тратить на это время, ибо все равно системя "я + ПЭВМ" работает не быстрей, чем самый медленный элемент системы. В этой системе медленным элементом являюсь я:) А к "микроподвисаниям" секунды на две--три (максимум, по ощущениям, чуть больше пяти) я уже привык.

Фигасе "микро", тут если в 0.5 секунды рывок возникает - уже рука тянется к дробовику, а вторая - к бутылке... Всё дело в том, что на железе быстрее 1.2-1.5 гигагерц такого просто тупо не бывает.

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

Удивительное рядом, и оно ещё имеет наглость тормозить...

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

странно, а межделмаш хочет заменить 3900 своих мелких сервером на 30 мейнфреймов с линуксом -- говорит за 5 лет съэкономит $250 млн

> Ахахах. Клоун! Так и вижу дружественный Linux Ubuntu или SuSe: юзер запускает окно затем запускает консоль, делает sudo renice -10 `pidof {прога}` затем при смене активного окна снова идет в консоль. делает renice 0 `pidof прога`; renice -10 `pidof прога2` =)))))))))

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

> Linux это и есть серьезная система, а твоя умирающая сопляра, которую ты тут пеаришь - тормозная распальцованная фигня с энтырпрайз дырами.

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

Правда вряд ли они будут красноглазого студента-недоучку слушать, с более приличествующим реперу из Гарлема гонорком.

> странно, а межделмаш хочет заменить 3900 своих мелких сервером на 30 мейнфреймов с линуксом -- говорит за 5 лет съэкономит $250 млн

Ну дык правильно, сколько лет тем "серверам"? А раз уж "мелкие", то и частота невысокая и процов мало, следовательно паверов №6 нужно немного, следовательно сие оправдано, и "мейнфреймы" те не сильно уж и толстыми будут. Как раз получится где-то близко к потолку линукса.

Да и сравнил маленький энтерпрайз и потребности отрасли в масштабах планеты...

> Да, тяжело поддерживать несколько планировщиков одновременно. Но и

> Линукс уже не игрушка

Cколько планировщиков в BSD, Solaris, HP-UX?

> А к "микроподвисаниям" секунды на две--три (максимум, по ощущениям, чуть больше пяти) я уже привык. Да и квалификация моя не позволяет лазить больше определенного по /etc; (б) под MS Windows моя квалификация тоже не позволяла мне лазить по реестру дальше, чем необходимо. Но там таких тормозов не было никогда.

что-то у Вас с линуксом не в порядке , у меня он начинает подтормаживать только при копировании на флешку (когда ж они этот глюк с vfat'ом исправят?!!!).

100% загрузка компилятором или базой на лазении по вебу или набирании текста вообще не сказывается. Вот новые программы запускаются чуть дольше.

> т.е. есть подозрение, что один нормальный планировщик отлично решает

> все проблемы

Именно так. Stellar просто не знает о такой фиче, как renice... (смотрите, сейчас потекут слюни и сопли на тему того, в каких он проектах работал, и сколько всего написал :)) Этот дятел уже настолько опух, что мнит себя программером, который может поучить жизни Линуса Торвальдса. Шетухин, ты дебил. Говорю тебе как человек, который лично с тобой знаком. Иди лечи комплекс неполноценности.

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

Файловая система Reiser дублирует функции ext3, как и O(1) шедуллер дублирует функции CFS.

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

Я анонимус, Коллективный Разум ЛОРа, поэтому мне не положено ни с кем церемониться по статусу. :) Просто прецедент с длублированием функции - будь то APM/ACPI, IO-шедуллеры и тд есть и нет НИ ОДОГО разумного довода и препятствия чтобы сделать один планировщик CPU умолчальным, а второй - опционально-экспериментальным и выбор планировщика оставить за пользователем(при выборе отрабатывает система #define-ов и включает код выбранного планировщика).

Кстати, недавно тут cfs-патчик накатил и решил прогнать крэш-дамп, что там рядом у Молнара лежит: 4 ядра => 400 процессов, 15 минут работы, весь процессор сжирается вчистую, loadavg до ~550 доходил, все дрова - открытые => никаких проприетарных скрытых ускорялок.

Ну так вот, даже в таком раскладе система (Гномовский DE => окошки) работала быстрее по ощущениям, чем голый флюксбокс на p3-667 в своё время.

Удивительно, вообще, как тут местные ананимусы что-то хаять умудряются.

> Фигасе "микро", тут если в 0.5 секунды рывок возникает - уже рука тянется к дробовику, а вторая - к бутылке... Всё дело в том, что на железе быстрее 1.2-1.5 гигагерц такого просто тупо не бывает.

Дык... я ж сначала поставил SUSE 10. Потом отключил все, что смог отключить сразу. Потом меня по старой памяти потянуло на эксперименты (лет семь-восемь назад у меня рабочей системой была Slackware 4.0, потом Slackware 7.0...). Потом вставил как-то раз диск с OpenSUSE 10.1 и сказал обновись. Оно и обновилось. Кажись здесь и появились тормоза:) А потом и OpenSUSE 10.2 в руки попались ISO'шники. Ну я и обновился еще раз:) Такой винегрет получился, что только держись:)

Одно утешает --- /home и прочие ценные данные изначально по специальным разделам распиханы. Думаю после следующего обновления сразу Arch ставить:D

> Cколько планировщиков в BSD, Solaris, HP-UX?

вот потому планировщик соляры и не подходит для десктопа. А во фре, говорят, его допилили

> Я анонимус, Коллективный Разум ЛОРа, поэтому мне не положено ни с кем церемониться по статусу. :) Просто прецедент с длублированием функции - будь то APM/ACPI, IO-шедуллеры и тд есть и нет НИ ОДОГО разумного довода и препятствия чтобы сделать один планировщик CPU умолчальным, а второй - опционально-экспериментальным и выбор планировщика оставить за пользователем(при выборе отрабатывает система #define-ов и включает код выбранного планировщика).

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

> Дык... я ж сначала поставил SUSE 10. Потом отключил все, что смог отключить сразу. Потом меня по старой памяти потянуло на эксперименты (лет семь-восемь назад у меня рабочей системой была Slackware 4.0, потом Slackware 7.0...). Потом вставил как-то раз диск с OpenSUSE 10.1 и сказал обновись. Оно и обновилось. Кажись здесь и появились тормоза:) А потом и OpenSUSE 10.2 в руки попались ISO'шники. Ну я и обновился еще раз:) Такой винегрет получился, что только держись:)

> Одно утешает --- /home и прочие ценные данные изначально по специальным разделам распиханы. Думаю после следующего обновления сразу Arch ставить:D

Когда я поставил 10-ю Зюзю... то получил психотравму, последствие которой проявляются по сей день. Так не тормозила даже венда с VESA-видеодрайвером и с отключенным DMA для винтов... Если Вы на оном чуде просидели больше месяца, то "ыыыыыы", я бы умер...

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

Нда. Ты хоть понимаешь своей дубиновой головушкой какой бред ты несешь? Речь была о динамическом изменении приоритетов СИСТЕМОЙ, ее планировщиком, а не пля о графических фронтендах к sudo renice.

> Поди песочку принеси, дядя, и расскажи серьёзным ребятам,

Это ты штоле серьезный дядь? Хм. Я думаю, что ты просто клоун с ЛОРа.

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

Поправка. На жалких 4000 процессоров, о коорых сопляра, проприетарное быдлоподелие как и венда, с ынтырпрайз пинг оф дэц и ремут и локал(дыра в passwd ЖЖОТ!) рутами в телнете(C C C C C C C C C C C C C C C C C C root RELOADED =) ) еще не выросла из своих просСАНных подгузников, хехе. Иди гипсику принеси и тазик с водичкой серьезным дядям которые тебе щас дадут линк на top500.org.

> ... нет НИ ОДОГО разумного довода и препятствия чтобы сделать один планировщик CPU умолчальным, а второй - опционально-экспериментальным...

Вот-вот. Для того и существуют опционально-экспериментальные ветки ядра. Там -ck, например.

> Файловая система Reiser дублирует функции ext3, как и O(1) шедуллер дублирует функции CFS.

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

Проще говоря. Сделали экспериментальную FS. Народ попользовался. Оказалось удачно. Крупные заказчики мигрировали на FS. Поддержка нужна? Нужна.

А с шедулером такая ситуация как выглядит?:D

> Удивительно, вообще, как тут местные ананимусы что-то хаять умудряются.

Это неправильные ананимусы крошат батон на CFS. Все правильные анонимусы знают что CFS рулит да так, что даже сопляре не снилось! :)

ААААААААААА ПППЦ КАПЧА "hyeten" )))))))))))))))))))))

> Это неправильные ананимусы крошат батон на CFS. Все правильные анонимусы знают что CFS рулит да так, что даже сопляре не снилось! :)

Дык ты подпись ставь, что-ли. Типа надо розовую леночку правильным ананимусам - и свастику какую-нибудь, отстрел облегчающую, на некошерных, и задачу обвески сим стаффом возложить на дописывающийся AI ЛОРа.

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

Тебе что-нибудь говорит слово опциональный/экспериментальный? Представь себе как-то сопровождают опциональный, вроде дров для семисегментного индикатора, и экспериментальный код и не жужжат.

> А с шедулером такая ситуация как выглядит?:D

Кому нужен CFS - использует CFS, который можно сделать основным планировщиком. Кому нужена сложность O(1) - собирают свое ядро сами с шедуллером O(1) и используют. В чем проблема?

> Нда. Ты хоть понимаешь своей дубиновой головушкой какой бред ты несешь? Речь была о динамическом изменении приоритетов СИСТЕМОЙ, ее планировщиком, а не пля о графических фронтендах к sudo renice.

Как в венде чтоль? Чтоб такое же тормозилово и глюкалово было? Когда можно лишь работать только с активным окном, тогда как всё остальное копошится в свопе? Дык ты ещё телепатический модуль не дописал. Иди работай, солнце ещё высоко.

> Это ты штоле серьезный дядь? Хм. Я думаю, что ты просто клоун с ЛОРа.

Полагаешь, сие есть взаимоисключающие ипостаси?

> Поправка. На жалких 4000 процессоров, о коорых сопляра, проприетарное быдлоподелие как и венда, с ынтырпрайз пинг оф дэц и ремут и локал(дыра в passwd ЖЖОТ!) рутами в телнете(C C C C C C C C C C C C C C C C C C root RELOADED =) ) еще не выросла из своих просСАНных подгузников, хехе. Иди гипсику принеси и тазик с водичкой серьезным дядям которые тебе щас дадут линк на top500.org.

Иди давай за песочком, существо эпилептическое, линупс даже на 16-32 ядрах на высокой многонитевой нагрузке сливать начинает даже уступающим по пиковой производительности системам на соляре и спарках, что уж там говорить о тысяче. Не говоря уже о том, что система с непрерывным адресным пространством на 4 тыщи ядер - это из твоих влажных подростковых снов явление, все нормальные люди на таких масштабах кластеры делают, либо несколько мейнфреймов ставят, либо это специализированные единичные решения и широкой публике оные недоступны.

> Тебе что-нибудь говорит слово опциональный/экспериментальный? Представь себе как-то сопровождают опциональный, вроде дров для семисегментного индикатора, и экспериментальный код и не жужжат.

Конечно говорит. Но если разработчик альтернативного экспериментального опционального тестирующегося (ТМ) шедулера слил Торвальдсу, Мортону и Молнару скопом, закатив истерику и показав отсутствие булатной крепости духа и устойчивости к невзгодам, то что дальше? И планировщик такой же делать, что сольёт в случае чего, типа "автор был Эмо, ему было плохо и грустно, следовательно код оказался недописанным и неоттестированным"?.

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

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

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

1) его масштабируемость никакая, 1 цпу в компе, 2 или 16 - в любом случае он от этого не выигрывает, это очень плохо, поскольку 2х ядерные цпу уже стандарт

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

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

http://lists.freedesktop.org/archives/xorg/2004-November/004336.html

> ... а ядро относится к нему как к одному процессу ничего не зная о клиентах...

Оба на. Похоже, что-то новое узнал. Оно и в самом деле так?

В таком разе спасибо за науку:up: Пошел читать по ссылке.

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

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

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

В общем случае стоит внести поправку - приложения могу висеть на одном ядре, а сервак иксовый обсчитываться другим. Без малейших проблем. Постоянный же перескок с ядра на ядро очень хорошо показываются дровами от nvidia серии 9ххх с введёнными многопоточными оптимизацями и включением опции UseEvents в xorg.conf + Бериле: 3-4-5 секундные фризы при прыжках между ядрами, на каждом скачке нагрузки на видяху (открытия окон, масштабирование оных, эффекты и т.п.). Ужас неописуемый.

> линупс даже на 16-32 ядрах на высокой многонитевой нагрузке сливать начинает

Но на самых крупных SMP (SGI Altix) стоит именно Линукс. Абыдна, да? :-P

> система с непрерывным адресным пространством на 4 тыщи ядер - это из твоих влажных подростковых снов явление

SGI такие чуть ли не серийно выпускает. И работает на них Linux.

> Но на самых крупных SMP (SGI Altix) стоит именно Линукс. Абыдна, да? :-P

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

> SGI такие чуть ли не серийно выпускает. И работает на них Linux.

Дык говорю тебе, у них своя ниша, и с HPC я не спорю. Приём? :)

Альтикс 4700, топовый - 512 сокетов на ноду, 1024 процессора максимум (таки итаники), с непрерывной памятью. Э, раньше это типа мной описано не было? :)

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

очевидно, это даже не обсуждается. я говорил про исполнение именно в main-loop х-сервера

Рекомендуется к прочтению: http://www.sgi.com/products/software/msoft/

> очевидно, это даже не обсуждается. я говорил про исполнение именно в main-loop х-сервера

А смысл? Всё равно видеокарта рисует, особенно при нынешних тенденциях использования OpenGL нижним слоем, такое впечатление, что прям немереное количество графики отображать приходится в реальном времени, что нужна масштабируемость аж на 16 процов и 32 ядра. Может каждой программе всё-таки своё оставим? ;)

> В таком разе спасибо за науку:up: Пошел читать по ссылке.

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

>1024 процессора максимум (таки итаники), с непрерывной памятью. Э, раньше это типа мной описано не было? :)

Тобой было написано это:

Gharik> линупс даже на 16-32 ядрах на высокой многонитевой нагрузке сливать начинает

"Где правда, брат?" (c)

А это?

Gharik> "cистема с непрерывным адресным пространством на 4 тыщи ядер - это из твоих влажных подростковых снов явление"

Так вот, есть SGIшные машины с 4096 (и 16384) процессорами. Наверное, не серийные пока - но реально существующие. На OLS2007 о них был доклад.

> А смысл? Всё равно видеокарта рисует, особенно при нынешних тенденциях использования OpenGL нижним слоем, такое впечатление, что прям немереное количество графики отображать приходится в реальном времени, что нужна масштабируемость аж на 16 процов и 32 ядра. Может каждой программе всё-таки своё оставим? ;)

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

> Тобой было написано это:
> Gharik> линупс даже на 16-32 ядрах на высокой многонитевой нагрузке сливать начинает
> "Где правда, брат?" (c)

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

> А это?
> Gharik> "cистема с непрерывным адресным пространством на 4 тыщи ядер - это из твоих влажных подростковых снов явление"
> Так вот, есть SGIшные машины с 4096 (и 16384) процессорами. Наверное, не серийные пока - но реально существующие. На OLS2007 о них был доклад.

Дык на килопроцессорный сервак и ядро Зюзевское специальным образом патчили, чтобы всё заработало, была ж новость на ЛОРе в стародавние времена, и феерический косяк в линупсе - создавалось столько ядерных потоков, что на пользовательские уже ничего не оставалось. Энтерпрайз система, где много чего предусмотрено и крутые шедулеры? ;)

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

Вроде бы эти 2 явления очень мощно взаимосвязаны, разве нет? В Бериле, вон, всё очень здорово враз становится, и окошки перестают отрисовываться со следами при перетаскивании, и реакция их улучшается враз, и всё это без всякой многопоточности.

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

> Правда в лучшей масштабируемости солярки и её значительно лучшей работе под __большой__ нагрузкой

Ну-ка, где у нас Соляра работала на 1024-процессорной железке? :D

> и ядро Зюзевское специальным образом патчили, чтобы всё заработало, была ж новость на ЛОРе в стародавние времена

В стародавние ;) кроме того - сейчас требуются довольно тривиальные патчи, а Linux - так и остается Linux'ом.

> Ну-ка, где у нас Соляра работала на 1024-процессорной железке? :D

Что-то я не в состоянии уловить величину шага, то у нас 16 процессоров, то 1024. Где истина __твоя__, брат? :) Да и не требуется это Солярке, железо там совсем другое и под другие цели заточено. Нууу, скажи, порадуй старика, что ты всё понял, а? :)

> В стародавние ;) кроме того - сейчас требуются довольно тривиальные патчи, а Linux - так и остается Linux'ом.

Да знаешь, как поглядишь на всякие современные труЪ-откорпораченные дситры, так и захочется переодеться троллем, поставить на ноут слаку и уйти в лес, жить на GPRS'е.

P.S. и вообще, забороли меня зомбифицирующиеся ананимусы, потрясающие 3-ми пентиумами и дерущиеся многочисленными планками ОЗУ под это дело, а так же лица с необъяснимыми тормозами десктопа под Зюзей, поклонники многонитевого рендеринга двумерной графики и прочие сочувствующие. Пойду выпью, епть.

> Постоянный же перескок с ядра на ядро очень хорошо показываются дровами от nvidia серии 9ххх с введёнными многопоточными оптимизацями и включением опции UseEvents в xorg.conf + Бериле: 3-4-5 секундные фризы при прыжках между ядрами, на каждом скачке нагрузки на видяху (открытия окон, масштабирование оных, эффекты и т.п.). Ужас неописуемый.

> Вроде бы эти 2 явления очень мощно взаимосвязаны, разве нет? В Бериле, вон, всё очень здорово враз становится, и окошки перестают отрисовываться со следами при перетаскивании, и реакция их улучшается враз, и всё это без всякой многопоточности.

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

> Пойду выпью, епть.

ты это, сёдня не пятница с утра была, или у тебя каждый день праздник ;) ?

> Что-то я не в состоянии уловить величину шага, то у нас 16 процессоров, то 1024. Где истина __твоя__, брат? :)

Моя - в том, что под реально тяжелой нагрузкой на реально многопроцессорных тачках Соляру просто не запускают :D

> Нууу, скажи, порадуй старика, что ты всё понял, а? :)

Да я сам старик, и давно всё понял :) А распинаюсь - молодежи ради :D

хм.. про микрозависания - могу подтвердить факт наличия.

2.6.16.27 Athlon 3800+. 2Gb RAM

действительно, всё как описывает чел. Зависание секунд на 5. грешу на огнелиса (1.5).

> ты это, сёдня не пятница с утра была, или у тебя каждый день праздник ;) ?

А я бедный аспирант и не работаю, поэтому хенеси каждый день ближе к вечеру - это хорошая практика ;)

ссылочку можно?