MySQL работает на Solaris-10 от 60% до 90% быстрее чем на RHAS4

Ага! "Булошная", "прачешная" и т. п.- основы русского литературного языка.. :)

да ни кто и не обижается :) я немного неправильно сказал, нужно: "за основу русского РАЗГОВОРНОГО литературного языка".

> .oO( мяядуза, цилафаан...)

Рязанский говор.

> Ага! "Булошная", "прачешная" и т. п.

А так же "дощь" и т.п. - старорусский говор. Вы еще про добавление "с" к концу слов вспомните, знатоки :-)

с удовольвствием-с :))) кста о рязанском говоре. Пару лет назад проезжая мимо города Скопин рязанской области на автобусной остановке увидел объявление: "Продаётся свадебная платья. Тел. X-XX-XX". Бабки на остановке во всю щеголяли словами "дааа, Мань хорошая полотенцА", молодые мамаши обозначали сладости для своих чад трудновоспроизводимым словом "нЦака". Показалось забавным :)

>> Кто нибуть использует Solaris 10 не на Sparс в production?

>Видимо, на x86 в продакшене их как раз-то и больше - потому sparc системы и инсталляции на их базе довольно инертны - у многих до сих пор стоит solaris 8 (и вряд ли что то будут менять - зачем ломать то, что хорошо работает).

На X86 они нужны ещё меньше, есть Debian и Red Hat и заменять их на solaris пока нету смысла.

>MTS использует Solaris 10 на amd64.

Пора менять оператора :-(

> На OLTP - пингвин просто ложится и загибает лапки! На все что он способен - это принять ночной дамп чтобы потом всякие [CFEP]EO свои кубы строили .... :)

Кубы это из OLAP, а здесь OLTP...

> Ниразу не слышал эту фразу от тех, кто живет в пределах кольцевой, только от тех, кто вне ее.

Глобус Земли с т.зр. американцев наблюдать приходилось? Вот тут примерно то же самое. В скором времени ждём сенсационных докладов "Есть ли жизнь за пределами МКАД или там обитает только лимита?"

>Глобус Земли с т.зр. американцев наблюдать приходилось?

Ты про глобус США?

> вообще-то московский говор принят за основу русского литературного языка. Вы что-то имеете против литературного русского языка? :)

Основу русского литературного заложил А.С.Пушкин, а жил он отнюдь не в Маськве :)

Get The Facts from Sun...

http://www.blastwave.org/

а зачем тебе "нормальный package manager"?

только факты то того - жареные :)

> да ни кто и не обижается :) я немного неправильно сказал, нужно: "за основу русского РАЗГОВОРНОГО литературного языка".

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

Ну, что фанатики, и стоило так уж сильно кричать "Solaris фтопку" ?

> Говорить надо так, как пишешь, тогда проблем с пониманием у тебя не будет.

ну-ну, "тестирование", это значит у тебя от слова тесто? :-)

и ты на полном серьезе говоришь "чего", "легкий" и т.п. "как пишется"?

P.S.

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

>> да ни кто и не обижается :) я немного неправильно сказал, нужно: "за основу русского РАЗГОВОРНОГО литературного языка".

>Русский разговорный литературный??? Это что ещё за выкидыш Франкенштейна? Линк в студию, хочу это видеть и слышать. Говорить надо так, как пишешь, тогда проблем с пониманием у тебя не будет.

Как говорится, яндыкс вам в руки :) более распространённо этот "выкидыш Франкенштейна" называется "русский разговорно-литературный язык". Понимается язык правильной/литературной речи на русском языке, коему раньше наиболее интенсивно обучали на курсах дикторов ТВ и Радио.

Нехорошо господа сравнивать уровень развития инфраструктуры между Москвой, где операторов не счесть и другими городами, где их меньше. Современем ситуация подравняется, а сейчас приезжая к родителям приходится сидеть на GPRS от глючного Мегафона ((( уж казалось бы 17 километров от МКАДА

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

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

Миритесь и следите для начала за собой, а уж затем за другими )))

здорово. и теперь эти дикторы ходят в булошные за булошками. "матка, курка, млеко, булошка, шнелль !" :)

>только факты то того - жареные :)

А вот это ХЗ. Например в тестах SPECjbb_2005 Linux тоже конкретно в заднице, отсасывая как у Соляры так и у Виндов. Интересно однако что по этому поводу говорят в LKM - http://marc.theaimsgroup.com/?l=linux-kernel&m=114494015627121&w=2 Обсуждается широкий круг "версий" начиная от хреновой VM под Linux и уеб*щной loking модели java и отсутствием там пойнтеров и заканчивая уеб*ищной архитектурой Opteron 285.

<quote> Opteron peformance currently **SUCKS** with 2.6 series kernels under any kind of heavy I/O due to their cloning of the ancient 82489DX architecture for I/O interrupt access and performance. </quote>

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

>вот сравнение годичной давности, вроде тот же Solaris 10, линукс правда постарее и машинка не такая навороченная:

Соляра - никогда НЕ позиционировалась как ОС для пецуков. В отличие от лайнакса, который только начинают пробовать на конфигурациях > 4 процов и > 4 гигов, соляра уже 10 лет отлично пашет на железяках на порядок более крутых. Если бы тестили на 1-2 процовых пецуках с 2 гигами, то лайнакс почти навернякка выиграл бы. Если бы тестили на 100 процовых сервака с 256 гигами - лайнакс просто бы не завелся.

>...молодые мамаши обозначали сладости для своих чад трудновоспроизводимым словом "нЦака"

ага, а из мимо пролетающего пепелаца доносилось: клади кацэ - получишь гравицапу...

надеюсь ты был не за рулем? :)

>>только факты то того - жареные :)

>А вот это ХЗ. Например в тестах SPECjbb_2005 Linux тоже конкретно в заднице, отсасывая как у Соляры так и у Виндов. Интересно однако что по этому поводу говорят в LKM - http://marc.theaimsgroup.com/?l=linux-kernel&m=114494015627121&w=2 Обсуждается широкий круг "версий" начиная от хреновой VM под Linux и уеб*щной loking модели java и отсутствием там пойнтеров и заканчивая уеб*ищной архитектурой Opteron 285.

><quote> Opteron peformance currently **SUCKS** with 2.6 series kernels under any kind of heavy I/O due to their cloning of the ancient 82489DX architecture for I/O interrupt access and performance. </quote>

>Кстати версий о том, что санки целый год подкручивали scheduler в соляре или тюнили ядро виндов никто так и не высказал а надо бы так ведь тестер?

Не надо вырывать фразы из контекста:

<q1>SpecJBB is a really frigging stupid benchmark. It's *much* more affected by the stupid crap in Java (like their locking model) than anything in the OS.

Best to find another benchmark, oh and preferably somebody vaguely objective to run it ;-)</q1>

<q2>This may be true, but on a more serious note someone should check to make sure Sun turned on hugepage support in the JVM under Linux.

That is one thing that helps this benchmark out enormously, so if hugepages are disabled you might as well ignore the result.</q2>

Джеф Мерки ламо то еще, так что слушать это чудо, что себя не уважать

>Соляра - никогда НЕ позиционировалась как ОС для пецуков. В отличие от лайнакса, который только начинают пробовать на конфигурациях > 4 процов и > 4 гигов, соляра уже 10 лет отлично пашет на железяках на порядок более крутых. Если бы тестили на 1-2 процовых пецуках с 2 гигами, то лайнакс почти навернякка выиграл бы. Если бы тестили на 100 процовых сервака с 256 гигами - лайнакс просто бы не завелся.

Еще одно чудо вылезло...

Linux прекрасно работает на системах от 1 до 1024 процессоров. А уж 32-64 - это поиграться хакеру на выходных, посмотри, как портировали на Sun T100.

Системный вызов в Linux занимает до 10 (!) меньше времени/тактов (обычно около 1.5), так что slowlaris, как бы чудесно его непредставляли, может выиграть только на задачах, заточенных именно под эту ОС.

>Не надо вырывать фразы из контекста:

Была фраза (цитата) про оптерон и только. То что бенчь сосет - вполне возможно. Однако странно что сосет он только под лайнем. Точнее под лайнаксом он сосет значительно медленнее чем под виндами и солярой.

>Джеф Мерки ламо то еще, так что слушать это чудо, что себя не уважать

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

>>Не надо вырывать фразы из контекста:

>Была фраза (цитата) про оптерон и только. То что бенчь сосет - вполне возможно. Однако странно что сосет он только под лайнем. Точнее под лайнаксом он сосет значительно медленнее чем под виндами и солярой.

Странные вы люди. Если за вас не переключили передачу, и вы все еще едете на первой скорости, то тоже будете утверждать, что автомобиль плохой?

>>Джеф Мерки ламо то еще, так что слушать это чудо, что себя не уважать

>Ну так скажи ему об этом лично. Обсирать людей за глаза - себя не уважать.

Было дело :) Его мало кто в серьез воспринимает, врочем, он тоже.

> Если бы тестили на 100 процовых сервака с 256 гигами - лайнакс просто бы не завелся.

здрасти. зайди и посмотри сколько в топ500 на линухе, а скока на солярисе: http://www.top500.org/sublist/

в топ40 13 на linux, 0 на солярис. еще вопросы будут?

>ну теперь-то венде конец!

товаристчи! цель популяризации соляриса поставлена SUN совместно с мелкософтом, и направлена не на "конец винде" а на "конец линуксу на серваках". Солярис как posix система конкурент не столько Windows(R) сколько именно линухе. В мире opensource обычное средство Майкрософта - агрессивный маркетинг оказывается слишком слабым оружием, и она вынуждена(!) таки использовать технологии. Но так как своих технологий представляющих адекватную альтернативу главному конкуренту у нее нет, приходится обращаться за помощью к своим "братьям по духу" - проприетарным UNIX. Вобщем ждите новых вестей как благоразумно SUN тратит подаренныt ей в 2004-м году почти два МИЛЛИАРДА долларов от майкрософта.

>в топ40 13 на linux, 0 на солярис. еще вопросы будут?

нормальные конторы (типа ЦРУ, NASA и т.д.) не "палят" свои выч. ресурсы на ширпотребных top500. И у них в основном НЕ линукс. Хотя и не без него. Линукс - действительно только по мере необходимости, а не из-за тупого фанатизма (везде во что бы то ни стало юзать линух) :)

>>Соляра - никогда НЕ позиционировалась как ОС для пецуков. В отличие от лайнакса, который только начинают пробовать на конфигурациях > 4 процов и > 4 гигов, соляра уже 10 лет отлично пашет на железяках на порядок более крутых. Если бы тестили на 1-2 процовых пецуках с 2 гигами, то лайнакс почти навернякка выиграл бы. Если бы тестили на 100 процовых сервака с 256 гигами - лайнакс просто бы не завелся. >Еще одно чудо вылезло... >Linux прекрасно работает на системах от 1 до 1024 процессоров. А уж 32-64 - это поиграться хакеру на выходных, посмотри, как портировали на Sun T100. >Системный вызов в Linux занимает до 10 (!) меньше времени/тактов (обычно около 1.5), так что slowlaris, как бы чудесно его непредставляли, может выиграть только на задачах, заточенных именно под эту ОС.

Я все готов понять... Но много ли установлено решений под линуксом от 16 процессоров и выше?

http://ru.sun.com/products/servers/highend/fireE25K/index.html - вот достаточно _массовое_ решение от сана. именно массовое, серийное, производимое в достаточных кол-вах; фишка не в этом - один и тот же дистрибутив солярис 10 работает на всей линейке санов без обточки дополнительной. фишка здесь. в машинке 72х2 камушка = 144 итого.

а сколько решений поставил sgi ? altrix, кажется, что там за линукс стоит? при том - альтрикс вешь уникальная и не серийная (IMHO, мало кому нужны голые вычисления, слишком ограничен круг задач). а кто еще что делает ?

а сколько ядер потянет rhas - ??? . из коробки ? http://www.redhat.com/rhel/details/limits/#two не нашел ничего толком, чтобы доказательную базу подвести - но 16 ядер/потоков - это все, на что способен линукс из коробки...

>IMHO OpenSource от SUN - это помогите нам делать нашу работу. >Редистрибьютить они не дают свое OpenSource продукты(например, я не >могу взять GlassFish и раздовать OpenSource решение на его базе), а >кому тогда такой OpenSource нужен?

Да-да! Как они задолбали на конференции своим GlassFish и JavaStudioCreator. И еще они так ложались - эти индусы долбанные! Народ с них ржал конкретно. Еще они конкретно офигели когда увидели что их сраным NetBeans пользуется 5 человек, а остальные eclipse и idea

>>IMHO OpenSource от SUN - это помогите нам делать нашу работу. >>Редистрибьютить они не дают свое OpenSource продукты(например, я не >>могу взять GlassFish и раздовать OpenSource решение на его базе), а >>кому тогда такой OpenSource нужен?

>Да-да! Как они задолбали на конференции своим GlassFish и JavaStudioCreator. И еще они так ложались - эти индусы долбанные! Народ с них ржал конкретно. Еще они конкретно офигели когда увидели что их сраным NetBeans пользуется 5 человек, а остальные eclipse и idea

Я сам пользуюсь Eclipse но на NetBeans смотрю с интересом, много вкусного из коробки. Ещё они похоже смогли сделать Swing UI приемлимым и местами даже приятным.

> Кстати версий о том, что санки целый год подкручивали scheduler в
> соляре или тюнили ядро виндов никто так и не высказал а надо бы так
> ведь тестер?

тесты которые никто повторить не в силах потому условия сокрыты годятся только для растопки

>Я все готов понять... Но много ли установлено решений под линуксом от 16 процессоров и выше?

>http://ru.sun.com/products/servers/highend/fireE25K/index.html - вот достаточно _массовое_ решение от сана. именно массовое, серийное, производимое в достаточных кол-вах; фишка не в этом - один и тот же дистрибутив солярис 10 работает на всей линейке санов без обточки дополнительной. фишка здесь. в машинке 72х2 камушка = 144 итого.

>а сколько ядер потянет rhas - ??? . из коробки ? http://www.redhat.com/rhel/details/limits/#two не нашел ничего толком, чтобы доказательную базу подвести - но 16 ядер/потоков - это все, на что способен линукс из коробки...

Любой каприз за ваши деньги: http://www-03.ibm.com/servers/systems/i/hardware/595/index.html, http://www-03.ibm.com/servers/eserver/clusters/hardware/index.html

И везде работает RHEL.

>Linux прекрасно работает на системах от 1 до 1024 процессоров

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

>А уж 32-64 - это поиграться хакеру на выходных, посмотри, как портировали на Sun T100.

Смотрел уже. Например сразу вылезла жопа с максимальным количеством одновременно открытых файлов с фрагментацией lowmem и полным зависанием ядра, куча проблем в smp связанных с синхронизацией, проблемы с планировщиком, полное избавление от семафоров и т.д. - все это вылезло именно в последние месяцы. До slowaris лайнаксу как от маськвы до пекина раком.

>Любой каприз за ваши деньги: http://www-03.ibm.com/servers/systems/i/hardware/595/index.html, http://www-03.ibm.com/servers/eserver/clusters/hardware/index.html

Аргумент %) Согласен ! Вопросы есть, конечно, но в целом...

> И везде работает RHEL.

можно маленький аргумент - там во втором случае разговор идет про кластер ... i5 595 - LPAR от ibm - технология - но dynamic domain's + containers от сана выглядят интереснее. Накладные расходы меньше. e25k - 18 доменов - 4CPU 64gig ram max. Это мнооого. При том, что подсистема ввода-вывода фактически не пострадает. IBM не хило на "иглу сажает" - лицензия на 4 CPU, дальше платим больше, еще, еще... С ibm всегда - "- is it clear? - mmm, no" :)

За ссылки спасибо, почитаю.

>Вобщем ждите новых вестей как благоразумно SUN тратит подаренныt ей в 2004-м году почти два МИЛЛИАРДА долларов от майкрософта.

А как? Сразу после жаба-Mustang выпустит жаба-Scapegoat?

>>Linux прекрасно работает на системах от 1 до 1024 процессоров

>Конэчно. Я не спорю что он запускается, но что толку от лошади, кот-рая бегает сама - надо чтобы она еще и телегу тащила. Тесты в частности от сун это прекрасно показывают.

Интересно, а Sun может опубликовать тесты, в которых не solaris выиграл?

>>А уж 32-64 - это поиграться хакеру на выходных, посмотри, как портировали на Sun T100.

>Смотрел уже. Например сразу вылезла жопа с максимальным количеством одновременно открытых файлов с фрагментацией lowmem и полным зависанием ядра, куча проблем в smp связанных с синхронизацией, проблемы с планировщиком, полное избавление от семафоров и т.д. - все это вылезло именно в последние месяцы. До slowaris лайнаксу как от маськвы до пекина раком.

С такой кашей в голове вы явно не в теме.

По пунктам.

1. "максимальным количеством одновременно открытых файлов" - не путайте теплое с мягким, вы некорректно сформулировали проблему с vfs. Нормальные люди не запускают 32*800 одновременно работающих процессов. Это все равно, что сказать, что oracle с 1тб базой медленно работает на Celeron 512Mb. В тестовом перегрузе система заявила, что она перегружена, какие вопросы?

2. "с фрагментацией lowmem" - вы начитались LOR о мозилле и ОО.О? фрагментация памяти может происходить из-за некорректного аллокатора, но это происходит в userspace, каждый может изобрести свой. Аллокатор Дага Ли (Doug Lee?) подходит длч большинства задач, вполне вероятно, что в каких-то он создает вынужденную фрагментацию. В ядре slab алокатор один и тот же, что в Linux (2.6?), что в solaris (кстати, в Linux он портирован из sunos).

3. "полным зависанием ядра" - на niagara? Что-то не припомню, но вполне вероятно, что включив overcommit и запустив несколько тысяч одновременно отъедающих память, активно работающих с VFS, и прочих, отъедающих CPU, процессов, вы не сможете залогиниться или интерактивность будет на нуле и т.п. Повторюсь, что система, находящаяся при такой перегрузке, не способна адекватно отражать происходящую действительность. Причем любая система.

4. "куча проблем в smp связанных с синхронизацией" - вы узнали модные слова и нашли знакомые буквы? О чем это вы?

5. "проблемы с планировщиком" - это наверное про интерактивность и apache? Было дело, но многопоточность здесь явно не при чем. В этом примере человек возмущался, что планирование для выделенных задач было _нечестным_, т.е. выделенная група не получала необходимого ресурса, но система в целом вела себя абсолютно корректно.

6. "полное избавление от семафоров" - интересно, каша была из топора или из хемикалия? Это вы либо про замену семафора ма mutex, либо о preemptible lock, либо о чем?

>До slowaris лайнаксу как от маськвы до пекина раком.

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

>С такой кашей в голове вы явно не в теме.

С таким говном в башке вы явно страдаете манией величия.

>Нормальные люди не запускают 32*800 одновременно работающих процессов. Это все равно, что сказать, что oracle с 1тб базой медленно работает на Celeron 512Mb. В тестовом перегрузе система заявила, что она перегружена, какие вопросы?

Вы товарисч не в теме. Просветитесь. И еще - мертвое зависание системы (помогает только кнопка reset) - лайнакс нынче так заявляет о перегрузке? Хотя пойнт не в этом. Лучше почитайте рассылку и просветлитесь.

<quote> I just wanted to report that I am hitting the "VFS: file-max limit xxx reached" problem quite easily on my 32-cpu Niagara machine with 16GB of ram with current 2.6.x GIT.

It seems far too easy to get a box into this state due to SLAB fragmentation and RCU. And once you get a machine into this state it is totally unusable. </quote>

>"с фрагментацией lowmem" - вы начитались LOR о мозилле и ОО.О? рагментация памяти может происходить из-за некорректного аллокатора, но это происходит в userspace, каждый может изобрести свой. Аллокатор Дага Ли (Doug Lee?) подходит длч большинства задач, вполне вероятно, что в каких-то он создает вынужденную фрагментацию.

Гы! Спасибо. Прасветили аднака. Только мима кассы! Фрагментация происходит(ла) из за ошибок в реализации RCU очереди для освобождения file сруктур. Просветлитесь.

>"полным зависанием ядра" - на niagara? Что-то не припомню, но вполне вероятно, что включив overcommit и запустив несколько тысяч одновременно отъедающих память, активно работающих с VFS, и прочих, отъедающих CPU, процессов, вы не сможете залогиниться или интерактивность будет на нуле и т.п.

Бред собачий. Войдите в тему.

>"куча проблем в smp связанных с синхронизацией" - вы узнали модные слова и нашли знакомые буквы? О чем это вы?

Да много всего было. Трудно вспомнить, а лазить по архивам - лень. На вскидку например недавно провлемы в ext3 были ( down() забыли или что то в этом роде ), куча мест, где синхронизацию спинлоками или мьютексами переделали на RCU, фьютексы новые и т.п. Что свидетельствует о том, что ну не устоялось все это, а только-только развивается и еще 10 раз переделается в отличие от, где это уже лет 10 как есть.

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

Гы! Ага! Только проблема в том, что образно говоря "expired" очередь может никогда нестать активной и приложения, которые мало спят будут ждать сколь угодно долго. Если это поведение называется корректным - я пас. Многопоточность здесь может и непричем, однако такое поведение проявляется только на сильнонагруженных системах. В этом смысл.

>Это вы либо про замену семафора ма mutex, либо о preemptible lock, либо о чем?

Это я о замене семафоров на мьютексы.

>И это очень хорошо, не нужно отличной системе превращаться в застывший гигантский неповоротливый труп.

Дурак ты башка. Это твой ляпикс вечно меняющийся нигде не стабильный. Одно слово just for fun, в то время как соляра - for the real work.

>>С такой кашей в голове вы явно не в теме.

>С таким говном в башке вы явно страдаете манией величия.

Если сравнивать с глупым анонимусом, то наверное да...

>>Нормальные люди не запускают 32*800 одновременно работающих процессов. Это все равно, что сказать, что oracle с 1тб базой медленно работает на Celeron 512Mb. В тестовом перегрузе система заявила, что она перегружена, какие вопросы?

>Вы товарисч не в теме. Просветитесь. И еще - мертвое зависание системы (помогает только кнопка reset) - лайнакс нынче так заявляет о перегрузке? Хотя пойнт не в этом. Лучше почитайте рассылку и просветлитесь.

><quote> I just wanted to report that I am hitting the "VFS: file-max limit xxx reached" problem quite easily on my 32-cpu Niagara machine with 16GB of ram with current 2.6.x GIT. It seems far too easy to get a box into this state due to SLAB fragmentation and RCU. And once you get a machine into this state it is totally unusable. </quote>

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

>>"с фрагментацией lowmem" - вы начитались LOR о мозилле и ОО.О? рагментация памяти может происходить из-за некорректного аллокатора, но это происходит в userspace, каждый может изобрести свой. Аллокатор Дага Ли (Doug Lee?) подходит длч большинства задач, вполне вероятно, что в каких-то он создает вынужденную фрагментацию.

>Гы! Спасибо. Прасветили аднака. Только мима кассы! Фрагментация происходит(ла) из за ошибок в реализации RCU очереди для освобождения file сруктур. Просветлитесь.

Бред. Вы говорите бред. В следующий раз хотя бы ссылки давайте. Для заметки освобождение иноды не может быть в RCU, т.к. для этого требуется контекст процесса.

>>"куча проблем в smp связанных с синхронизацией" - вы узнали модные слова и нашли знакомые буквы? О чем это вы?

>Да много всего было. Трудно вспомнить, а лазить по архивам - лень. На вскидку например недавно провлемы в ext3 были ( down() забыли или что то в этом роде ), куча мест, где синхронизацию спинлоками или мьютексами переделали на RCU, фьютексы новые и т.п. Что свидетельствует о том, что ну не устоялось все это, а только-только развивается и еще 10 раз переделается в отличие от, где это уже лет 10 как есть.

:)) понятно...

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

>Гы! Ага! Только проблема в том, что образно говоря "expired" очередь может никогда нестать активной и приложения, которые мало спят будут ждать сколь угодно долго. Если это поведение называется корректным - я пас. Многопоточность здесь может и непричем, однако такое поведение проявляется только на сильнонагруженных системах. В этом смысл.

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

>>Это вы либо про замену семафора ма mutex, либо о preemptible lock, либо о чем?

>Это я о замене семафоров на мьютексы.

Буга-га, вместо down -> mutex_lock, серьезное изменение, спору нет. Суть одна и та же у обоих вызовов, как и архитекурно зависимые части.

>>И это очень хорошо, не нужно отличной системе превращаться в застывший гигантский неповоротливый труп.

>Дурак ты башка. Это твой ляпикс вечно меняющийся нигде не стабильный. Одно слово just for fun, в то время как соляра - for the real work.

:) Работайте, только пожалуйста, не смешите людей публикациями о производительности solaris.

>здорово. и теперь эти дикторы ходят в булошные за булошками. "матка, курка, млеко, булошка, шнелль !" :)

LOL, лежу под стулом :-)) Все-таки ЛОР реально поднимает настроение :-))

>Если сравнивать с глупым анонимусом, то наверное да...

Маньяк он ведь вне всякого сравнения маньяк ибо это диагноз.

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

Слив защитан.

>Бред. Вы говорите бред. В следующий раз хотя бы ссылки давайте. Для

Бред несете вы. Ха! Какие ссылки? На исходники ядра?

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

Нда... Как все запущено! У меня к сожалению нет под рукой исходников, однако вот это предложенный патч, который вошел в 2.6.17 http://www.hill9.org/linux/kernel/patches/2.6.16-rc3/fix-file-counting.patch

Хотя ты наверняка невьедешь!

Кстати мой старый недрук - вот вам ссылка на lwn - почитайте. Специально для тебя нашел. http://lwn.net/Articles/174641/ . Они кстати тоже говорят что

The core of the problem, however is the use of the read-copy-update (RCU) mechanism for management of file structures. When a file is closed, the task of freeing the structure is queued in RCU. Using RCU lets the kernel ensure that the structure is not freed while references to it remain, but without the sort of locking overhead that comes with other techniques. As a result, performance is measurably improved on SMP systems.

Пожрите гамна неуважаемый.

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

>Слив защитан.

>>Бред. Вы говорите бред. В следующий раз хотя бы ссылки давайте. Для

>Бред несете вы. Ха! Какие ссылки? На исходники ядра?

Какой умный собеседник, определенно, анонимусы не развиваются...

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

>Нда... Как все запущено! У меня к сожалению нет под рукой исходников, однако вот это предложенный патч, который вошел в 2.6.17 http://www.hill9.org/linux/kernel/patches/2.6.16-rc3/fix-file-counting.patch

:)) ага, хранение полного количества открытых файлов в глобальных per-cpu переменных и проверка при открытии, очень актуально в свете дискуссии про освобождение структуры file, RCU и т.п.

Мой юный друк, я уже вижу, что вы являетесь эпизодическим читателем lwn, нахватались вершков о ядерном программировании и наверное даже подписаны на lkml или общаетесь с таковыми (на ЛОРе). К сожалению этого не достаточно, чтобы понимать, как устроено ядро Linux, однако этого более чем хватает для сравнений его с Solaris. Продолжайте в том же духе, стране нужен метан!

>Кстати мой старый недрук - вот вам ссылка на lwn - почитайте. Специально для тебя нашел. http://lwn.net/Articles/174641/ . Они кстати тоже говорят что

>The core of the problem, however is the use of the read-copy-update (RCU) mechanism for management of file structures. When a file is closed, the task of freeing the structure is queued in RCU. Using RCU lets the kernel ensure that the structure is not freed while references to it remain, but without the sort of locking overhead that comes with other techniques. As a result, performance is measurably improved on SMP systems.

>Пожрите гамна неуважаемый.

Ага, а теперь давайте вспоминать, о чем вы говорили сначала - правильно о "фрагментации lowmem" (какой термин!), а теперь будем думать, как работа RCU может повлиять на эту самую "фрагментацию lowmem"...

Порой очень забавно читать эдаких доморощенных студентов-первокурсников, подписанных на lkml в течение второго семестра, представляющих себе как устроен мир. Может быть вы и не студент уже вовсе, но несете такую ересь... Конечно Linux не без ошибок, но то, что вы здесь наплели пару сообщений выше, и что еще мне напишене - это просто в "мемориз" :)

>> вообще-то московский говор принят за основу русского литературного языка. Вы что-то имеете против литературного русского языка? :)

>Основу русского литературного заложил А.С.Пушкин, а жил он отнюдь не в Маськве :)

Не Пушкиным единым был сформирован литературный русский язык. Его формировали целый табун людей разного происхождения и разных взглядов. Молее-менее наукообразно он начал формироваться веком ранее ещё Ломоносовым (который ваще Архангельский мужик), основавшим универ не где-либо, а именно в Москве. Полагаю, что в связи с тем, что наука 18-19 веков в основном концентрировалась в Москве и были выбраны приоритеты, взятые за основу.

>ага, хранение полного количества открытых файлов в глобальных per-cpu переменных и проверка при открытии, очень актуально в свете дискуссии про освобождение структуры file, RCU и т.п.

When a file is closed, the task of freeing the structure is queued in RCU.

Это цитата с так любимой тобой lwn.

>Ага, а теперь давайте вспоминать, о чем вы говорили сначала - правильно о "фрагментации lowmem" (какой термин!), а теперь будем думать, как работа RCU может повлиять на эту самую "фрагментацию lowmem"...

Тебе же ссылку дали. Йоптыть! Читать не умеешь? Перевести тебе может бедолага?

But, if the generation of RCU callbacks continues at a high rate, the length of the callback queue can only grow. Every entry in the queue represents memory which could be returned to the system, but which has not yet been made available. So, as the queue grows, memory gets fragmented and the system heads towards the dreaded out-of-memory state.

Щеки иногда полезно СДУВАТЬ, а нето лопнешь и всех забрызгаешь своим дерьмом...

Гы! Ты незнаешь что такое lowmem? Теперь о том, что ТЫ говорил сначала:

1) Говорить о жопе, обнаруженной David Miller и приводящей к полному ступору системы иззи ОШИБКИ в обслуживании очереди RCU как о нормальном поведении

>В тестовом перегрузе система заявила, что она перегружена, какие вопросы?

- ВЕРХ БЕЗГРАМОТНОСТИ. ЗДУЙ ЩЕКИ.

2) Говорить о userspace и приплетать Lea аллокатор в контексте разговора о исчерпании lowmem - это ли не показатель безграмотности? Ты даже незнаешь что такое low memory - т.е. ты не имеешь представления о модели памяти в лайнаксе. ЗДУЙ ЩЕКИ НЕЗНАЙКА!

>В ядре slab алокатор один и тот же, что в Linux (2.6?), что в solaris (кстати, в Linux он портирован из sunos).

В ядре slab аллокатор был еще тогда, когда код соляры небыл открыт. И уже переделывался несколько раз из за проблем с фрагментацией. Хотя это непринцыпиально.

Говорить об ошибке в планировщике как о фиче

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

Более тупого и в КОРНЕ НЕВЕРНОГО замечания трудно было придумать! Конечно все можно "настроить" например исправив ошибку, что и было зделано "тупым" торвальдсом, который непослушался крутого rtc.

Забавно, ты выставлял себя крутым знатоком линуксячих потрохов и КАК ТЫ ОБОСРАЛСЯ! Спасибо за напоминание о lwn, теперь каждый может почитать и убедиться какой ты ЗАСРАНЕЦ. Мораль говорить небуду, хотя и сомневаюсь что ты сам додумаешься. Кстати - сейчас, пока есть время, поищу на lwn ссылку об ошибке в планировщике.

Вот ссылка об ошибке планировщика. Почитай ЩЕКАСТЫЙ.

>)) ага, хранение полного количества открытых файлов в глобальных per-
cpu переменных и проверка при открытии, очень актуально в свете 
дискуссии про освобождение структуры file, RCU и т.п.


Да, забыл ответить на этот ОПУС. Ты ЩЕКАСТЫЙ что не чиаешь ссылок, 
которые сам же клянчил? Нехорошо ... Я же тебе дал ссылку на фикс - лазил на gmane искал а ты ?


-/* slab constructors and destructors are called from arbitrary
- * context and must be fully threaded - use a local spinlock
- * to protect files_stat.nr_files
+static inline void file_free(struct file *f)
+{
+percpu_counter_dec(&nr_files);
+call_rcu(&f->f_u.fu_rcuhead, file_free_rcu);
+}


Эта муйня ставит в RCU очередь callback, который освободит  struct 
file.


+static inline void file_free_rcu(struct rcu_head *head)
+{
+struct file *f =  container_of(head, struct file, f_u.fu_rcuhead);
+kmem_cache_free(filp_cachep, f);
+}

А эта - и есть та самая, которая освобождает.


Все - больше спорить с тобой никакого фану нет. Обтекай.