Сравнительное тестирование нового шедулера в ядре

тсс ждем Мурыча

Ничё не понял - объясните где там смотреть различия?

Всё, врубился.
Metric - это время исполнения 100 процессов.

PS. Даже Мортон не сразу сообразил что там к чему. :-)

А чё? Ничё! Мне нравицца!

>As you look again and compare the times against the 1-way, 2-way, 4-way
>and 8-way systems, you see the times decrease as the number of
>processors in a system increase. This is also a good trend. And it
>seems to be a fairly good linear correlation as well, implying that

Все это конечно гуд. Однако разница между 1 и 8 процов ~100%.
Может оно конечно корреляция то линейная, но про масштабируемость
этого не скажешь. Где масштабиремость то линейная а?


Captain Nemo.

где-где :) - где и обычно :D

И ХХде это ты видел линейный рост пр-ти в масштабируемых системах (не SMP - да и в них тоже :)) ??? хАчУ (С) Я :))

anonymous: а чего ты от меня хочешь?

сравниваются current 2.6.0-test5 kernel и 2.5.28 development kernel..

нормально - надо бы еще завести current test-alpha, pre-test и test-stable а также dev-testing и dev-current и посравнивать их всех между собой в ожидании релиза нового ядра :)

вывод: SMP на двухпроцессорной машине - маркетинговый виебон и опасная (учитывая ограничения linux-SMP) ловушка для лохов. А конкретный китаец Ли-Ну-Их лобает свою примочку тока под китайские компы. dejanews собирало свою поисковую систему на 100 компах и про СМП сказало: "а засуньте СМП машины ..."

слышали, у Мурыча каша в голове кончилась, нам сегодня не достанется

Что за нелепые наезды на Linux-SMP? На любом двухпроцессорном сервере, на котором выполняется одновременно несколько процессоро-зависимых процессов SMP дает прирост производительности близкий к 200%. Проверял сам на сервере с Squid, DNS, Firewall. Добавление второго PIII 500 сразу решило проблему с задержками при открытии web-страниц.

Товарищ 2003-09-25 00:09:11.150151 видно не делал сам тестов на SMP ;) СУБД очень хорошо используют второй проц (собственно, другие задачи у нас не так нагружают систему чтобы был заметен прирост).

>процессоро-зависимых процессов

круто

>И ХХде это ты видел линейный рост пр-ти в масштабируемых системах (не
>SMP - да и в них тоже :)) ??? хАчУ (С) Я :))

Если 'хатите' - используйте БАБУ или левую руку ... или правую.

SUN например рекламирует линейный рост производительности при увеличении
количества процессоров до аж 100 штук. (Естественно Solaris и [x]Sparc).

Про 100 конечно 3.1415515956-здят (ну верю я), а на 8 - абсолютно точно.
( Ибо сам мерял. Хорошо распаралеленная счетная задача при увеличение
числа процессоров с 4 до 8 ускорялась ровно на 100% ).
Да и задача очень для такого рода тестов хороша - 100 процессов слушают
100 сокетов, а другие 100 пишут в них т.е. на уровне приложений все уже
максимально распаралелено.


Captain.

>(ну верю я) должно быть: (ну не верю я)

>ускорялась ровно на 100% должно быть: ускорялась примерно на 100% (усредненная цифра была где то в районе 95%, но там был еще и i/o на диск довольно больших массивов).

Captain.

дoлoй ненужные заимствoвания! шедулер суть планирoвщик.