Программист Intel нашел проблему масштабирования linux на SMP.

проблема, связанная с проблемой... мдааа коловорот слов :)

> проблема, связанная с проблемой

Это где ж такое?

хорошо!

Такая новость не может не радовать, пускай даже я и не пользуюсь восьмиголовыми процами :)

всего три строчки (см. патч) изменили мир к лучшему:)

>всего три строчки (см. патч) изменили мир к лучшему:)

+1 :)

хорошая новость

Да, это действительно радует. Интересно, подвержены ли более старые версии glibc, типа 2.4

Сходил, почитал... :) Аж c 2.3.

вот еще бы решил проблему с firefox наконец-то ;) Поставил аллокатор от openbsd все равно:

PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND

1482 asshole 15 0 303m 166m 29m R 0 18.8 firefox-bin

MySQL Performance Blog пока молчит :)

http://www.mysqlperformanceblog.com

PS: открыто 5 табов

Респект!

> всего три строки!
+1

> Интересно, подвержены ли более старые версии glibc, типа 2.4

Если по ссылке таки сходить, то можно будет увидеть ту же проблему на rhel4u3 c glibc 2.3 %)

У соляриса выбили из-под ног еще одну пузомерку? :-)

>У соляриса выбили из-под ног еще одну пузомерку? :-)

сравнение было линакс вс фряха. причем здесь соляра? на больную мозоль наступила?

в интерл правильные девелоперы сидят. эх, мне бы туда уехать... (ушел убивать себя об стену)

>сравнение было линакс вс фряха. причем здесь соляра? на больную мозоль наступила?

последнее сравнение было именно с соляркой
интересно а почему это не мешало ораклу первые места на tpc занимать на 128 ядрах ?

>вот еще бы решил проблему с firefox наконец-то ;) Поставил аллокатор от openbsd все равно:

Мысль вслух: прикрутить бы к нему pool-аллокатор от Apache, и тупо выделять по пулу на страницу, чтобы с закрытием оной этот пул уничтожать...

Кетаец - мужик!

>интересно а почему это не мешало ораклу первые места на tpc занимать на 128 ядрах ?

может он пользует свою собственную glibc?

> Программист Intel нашел проблему масштабирования linux на SMP.

я так понял по тексту, что программист из интел нашел РЕШЕНИЕ проблемы масштабирования linux на SMP, сама по себе проблема была известна до него, поправить бы заголовок надо

> всего три строчки (см. патч) изменили мир к лучшему:)

Ещё не изменили -- пока только временная затычка, чтобы проверить справедливость гипотезы о виновности glibc.

Между прочим, первым, кто указал, что ошибка кроется в glibc, был не
программист Intel, Yanmin Zhang, а программист SAMBA, Anton Blanchard.
Он же и провел первый тест не с GNU libc-шной реализацией malloc: http://ozlabs.org/~anton/linux/sysbench/

Anton Blanchard
date Mar 13, 2007 1:00 AM
subject Re: SMP performance degradation with sysbench
mailed-by vger.kernel.org

Hi Nick,

> Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
> at this, send me a mail (eg. especially with the sched_setscheduler issue,
> you might be able to do something better).

I took a look at this today and figured Id document it:

http://ozlabs.org/~anton/linux/sysbench/

Bottom line: it looks like issues in the glibc malloc library, replacing
it with the google malloc library fixes the negative scaling:

# apt-get install libgoogle-perftools0
# LD_PRELOAD=/usr/lib/libtcmalloc.so /usr/sbin/mysqld

Anton

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Причем, это он проделал еще за неделю до китайца

Уберите из новости эти слова:

> нашел причину проблемы масштабирования Linux на SMP

иначе это будет вызывающе неверной информацией.

"Новость" должна выглядеть так:

Программист Intel, Yanmin Zhang, прислал патч для glibc-2.5, исправляющий проблему масштабирования Linux на SMP, продемонстрированную красочными тестами с графиками провала роста производительности mysql на более чем 8-ми процессорах, которая так активно мусолилась весь предыдущий месяц.

Еще неделю назад, Anton Blanchard выяснил, что проблема оказалась вовсе не в ядре Linux, а в GNU libc (glibc), в функциях malloc/free.

ЗЫ: следовательно, новость в топку.

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

> всего три строчки (см. патч) изменили мир к лучшему:)

я как-то видел патч к коду на C++ который в одну строку и один kbiybq символ существенно изменил всю систему к лучшему, а тут целых три строчки...

// wbr

В нижнем новгороде еще есть, у меня туда знакомый уехал

>Интел есть в москве, есть в томске, есть в новосибирске (думаю есть еще где-то, просто я не в курсе). Куда тебе приспичило ехать? icc пишут в том числе и в россии (значительный кусок девелоперов).

я знаю. просто так выразился.

Не прислал патч.

The patch is just to verify my idea instead of the final solution.

Пока это патч для проверки этой идеи. И еще не оттестировано на AMD.

все-равно новость в топку

> MaratIK

Маратика несло и не попускало... :-)

Спасибо за правку, еще бы не помешало тему новости сменить.

хммм... китаец, а умный как русский. :)

вспомнил анекдот про обезьян - без обид

>сравнение было линакс вс фряха. причем здесь соляра? на больную мозоль наступила?

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

> интересно а почему это не мешало ораклу первые места на tpc занимать на 128 ядрах ?

Потому что Oracle не потоками работает, а процессами (вроде бы) И Postgres тоже по-этому лучше MySQL-а масштабировался

> еще бы не помешало тему новости сменить.

Новость совершенно верная. Программист интел конкретно нашел конкретно участок кода с конкретной пролемой. Кто _до_ него нашел участок кода, где именно проблема? И где об этом можно почитать? А то вони от тебя много, а толку что-то мало.

>я как-то видел патч к коду на C++ который в одну строку и один kbiybq символ существенно изменил всю систему к лучшему, а тут целых три строчки...

А у меня как-то иногда одна ветвь проги не работала. Поправилось изменением одного символа. :)



Изменим жизнь к лучшему (с) см. выше

>>я как-то видел патч к коду на C++ который в одну строку и один kbiybq символ существенно изменил всю систему к лучшему, а тут целых три строчки...

> А у меня как-то иногда одна ветвь проги не работала. Поправилось изменением одного символа. :)

неужели то-же '~' ?

// wbr

> Ещё не изменили -- пока только временная затычка, чтобы проверить справедливость гипотезы о виновности glibc.

куда катится мир? код УЖЕ воспринимается как некий чёрный ящик, которому проще дать сигнал на вход (тестовый патч) и смотреть на выход (производительность), чем разобраться как ЭТО работает. и это OS!

> код УЖЕ воспринимается как некий чёрный ящик, которому проще дать сигнал на вход (тестовый патч) и смотреть на выход (производительность), чем разобраться как ЭТО работает. и это OS!

хинт: кода много.

Да, malloc из google performance tools рвёт malloc из glibc на большом количестве процессоров. И это известно давно. Основная проблема с масштабируемостью программ (особенно написанных на C++ -- больно уж много работы с динамической памятью в стандартной библиотеке) на large SMP -- плохая масштабируемость malloc().

Всем, кто хочет знать, каким должен быть malloc для SMP -- вот сюда: http://google-perftools.googlecode.com/svn/trunk/docs/html/tcmalloc.html

:)

>в интерл правильные девелоперы сидят. эх, мне бы туда уехать... (ушел убивать себя об стену)

Да-да, поедь к ним, и объясни что крепления для кулеров они делают говняные! И что процессор это "для считать", а не кремниевый нагреватель.

> icc пишут в том числе и в россии (значительный кусок девелоперов).

Вроде, уже не пишут.

> всего три строчки (см. патч) изменили мир к лучшему:)

Это только PoC, а не final solution.

Написали таки окончательно?

"Порадовал" комментарий прямо перед пропатченными строками.

Выходит, что этот Yanmin "писатель" ;(