LINUX.ORG.RU

Результаты сравнения масштабируемости в ядрах версии 2.4 и 2.6


0

0

Крейг Томас выложил очень интересные результаты бенчмарка между планировщиком в ядре 2.4 и O(1) планировщиком в ядре 2.6. Для бенчмаркинга использовался hackbench - программа, написанная Rusty Russell для тестирования производительности системы. Как и следовало ожидать, планировщик в ядре 2.6 более эффективен и позволяет достичь более высокой масштабируемости на больших системах.

>>> Результаты и графики сравнения

★★★★★

Проверено: maxcom

Ответ на: комментарий от dpkg

>2.4.18 да... они бы еще 2.2 взяли...

А какие significant changes были сделаны в планировщике в версии ядра 2.4.23 начиная с 2.4.18?

dotcoder ★★★★★
() автор топика

На самом деле все эти бенчмаки практической ценности не имеет - ну скажите кто реально в Prodaction использует базовое ядро (ну кроме доморощенных хакеров конечно) ?

А Все вендоры (RedHat, SuSE etc) уже давно все что надо из 2.6 взяли

Я тут пытался сравнить 2.4.21-EL (Ядро от RH AS 3.0) с 2.6 на 8 процессорной железке и был весьма разочарован тем что 2.6 было значительно медленнее как на CPU Bound Loads так и на Disk Bound Loads.

anonymous
()

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

ananymous
()

Результаты просто впечатляющие. "O(1) планировщик" оправдывает свое название с удивительной точностью.

А не знает ли кто-нибудь, когда ASP или ALT начнут поддерживать новое ядро в своих дистрибутивах (если уже не начали, конечно)?

dave ★★★★★
()
Ответ на: комментарий от Shaman007

>На самом деле все эти бенчмаки практической ценности не имеет - ну скажите кто реально в Prodaction использует базовое ядро (ну кроме доморощенных хакеров конечно) ?

во первых это называется prod_U_ction

а во вторых все нормальные люди vanilla и используют

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

anonymous
()
Ответ на: комментарий от anonymous

Речь не идет о доморощенных патчах а о наборе которые используют Вендоры, которые кстати могут позволить себе нормальный QA в отличии от Марсело

Ну назовите хоть один Крупный Западный проект которые бы использовал самодельное ядро ? К нему же кстати и никакой коммерчиской поддержки

anonymous
()
Ответ на: комментарий от anonymous

Если вендоры, которые могут позволить себе qa это бывшая красная шляпа и т.п.. То мне такого qa не надо. Спасибо, плавали, знаем. Никогда не забуду как у меня mysql в продакшине валился раз в день только из-за того что "вендор" позволил себе qa и налепил патченый gcc-2.96. А потом собрали им дистр и mysql. А от того что у них есть комерческая поддержка мне легче не стало, и mysql падать не перестал. Только деньги потратили на эту шляпу и "коммерческую поддержку".

У вас такая наивная вера в то что если дадите дяденьки доллар, то он вам что-то такое обеспечит типо qa. Вам пора выкинуть розовые очки.

anonymous
()
Ответ на: комментарий от anonymous

хех. ну дык нормальные люди как раз и берут ванильное ядро и ставят туда grsecurity как минимум (с редхатом это не идет).

FreeBSD ★★★
()
Ответ на: комментарий от anonymous

Не С RedHat все понятно - их Десктопная версия это реально Бета по сути дела для обкатки новых технологий. А серверные версии вполне стабильные и с хорошим QA.

Думайте почему AS с NTPL и прочими вкусностями вышел через столько времени после RedHat 9 ?

anonymous
()
Ответ на: комментарий от anonymous

естественно у меня была серверная версия на сервере, то еще г

не дома же я базы пускаю

anonymous
()
Ответ на: комментарий от ananymous

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

Очень странно.... А затем ты поставил оракл и он у тебя залетал!?...
Либо ты 3.14здишь, либо ты не про RHES/AS v.3...

anonymous
()
Ответ на: комментарий от anonymous

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

Почему бывшая?????

anonymous
()

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

Винда рулез, или как? :)

anonymous
()
Ответ на: комментарий от anonymous

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

В то время Линукс действительно рулил, а сейчас рулит еще больше... Что-то непонятно? :)

Потому-что мы можем... (С) Инго Молнар (по-моему)

dotcoder ★★★★★
() автор топика
Ответ на: комментарий от dotcoder

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

OpenStorm ★★★
()
Ответ на: комментарий от anonymous

PaX тормозит?

2 anonymous (*) (06.12.2003 21:29:45)

> grsecurity с paxом тормозиииииииит!

Если Вы являетесь счастливым обладателем процессора, разработчики которого решили сэкономить на page executable bit, выключите опцию CONFIG_PAX_PAGEEXEC и пользуйтесь CONFIG_PAX_SEGMEXEC=y

x86 suxx!

Dselect ★★★
()
Ответ на: комментарий от dave

> А не знает ли кто-нибудь, когда ASP или ALT начнут поддерживать новое ядро в своих дистрибутивах (если уже не начали, конечно)?

А не знает ли кто-нибудь, когда ASP или ALT начнут поддерживать НОРМАЛЬНО СОБИРАЮЩЕЕСЯ новое ядро в своих дистрибутивах (если уже не начали, конечно)? Почему ядра с www.kernel.org ВСЕГДA без проблем (или почти без проблем) собираются, а с ASP рационализацией ядра, проведённой народными умельцами разбираться надо?

anonymous
()
Ответ на: комментарий от anonymous

еще про тормозящий PaX

2 anonymous (*) (08.12.2003 13:38:01):

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

Главным образом -- RTFS.

Dselect ★★★
()
Ответ на: комментарий от anonymous

> Ты хоть сам понял, что сказал?

Я понял. А ты - нет? Если ты не понял вопроса, то зачем отвечаешь? =)

anonymous
()
Ответ на: комментарий от anonymous

> тебе уже ответили: раньше Линух рулил, а сейчас новый линух обруливает старый

Да, он, наверное, думает, что "новые версии ядра" - это, как "патчи" у Windows: отдельно - для `XP, отдельно - для `2000, а у Linux: отдельно - для RedHat, отдельно - для Debian, etc...

Я угадал?

anonymous
()

Действительно - очень интересные результаты. Из первых же 4 графиков для 1.2.4.8 процессоров соответственно следует, что 2.6 умеет пользоваться многопроцессорностью (время выполнения теста уменьшается при увеличении кол-ва процессоров), а 2.4.18 - толком не умеет. 8 процессорная машина с 2.4.18 выполнила этот всего тест на несколько процентов быстрее чем 1 процессорная !!!

Машинки конечно разные, но процессора то все примерно одинаковые - PIII от 700 Мгц (8 процессорная) до 1 ГГц (1 процессорная).

цитата - The results in the 2.4.18 graph show that the performance is nearly indistinguishible on a 2-way and an 8-way system when the number of process groups approach 150.

То есть быстродействие 2-х процессорной системы практически такое же что и 8 процессорной.

Второй интересный результат - на 2.4.18 лучше работает 4-х процессорная система чем 8 процессорная ! и это при _одинаковых_ процессорах, хотя и немного разных чипсетах.

С 2.6 же все как и ожидалось - больше процов - больше быстродействие

Ау, SCO - нах нам не сдался такой SMP, забирайте обратно свой SMP код из 2.4

anonymous
()
Ответ на: комментарий от anonymous

>Если Вы являетесь счастливым обладателем процессора, разработчики которого решили сэкономить на page executable bit, выключите опцию CONFIG_PAX_PAGEEXEC и пользуйтесь CONFIG_PAX_SEGMEXEC=y

А если у меня памяти 2.5Г то один гиг тоже выкинуть?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.