26 октября 2011 в 14:26

Есть ли польза от кастомных ядер

Многие слышали о различных оптимизированных и улучшенных ядрах, это — Zen Kernel и pf-kernel из известных мне. Кроме того, что они добавляют новые возможности (TuxOnIce, поддержка aufs), они могут улучшить производительность, благодаря улучшенному менеджеру задач (BFS) и планировщику (BFQ). В этом топике я хочу сравнить производительность pf-kernel со стандартными ядрами в Ubuntu и Arch Linux, а также описать процесс сборки и установки pf-kernel для Ubuntu. Тестировать Zen Kernel я не вижу особого смысла, т.к. во-первых, проект выглядит заброшенным, а во-вторых, набор патчей и там и там очень похожий.

Тесты

Arch Linux

Начнем с теста Arch Linux на нетбуке.
Результаты теста UnixBench на стандартном ядре (3.0-ARCH):

Test	Score	Unit	Time	Iters.	Baseline	Index
Dhrystone 2 using register variables	3432673.5	lps	10.0 s	7	116700.0	294.1
Double-Precision Whetstone	821.7	MWIPS	10.2 s	7	55.0	149.4
Execl Throughput	1048.3	lps	29.7 s	2	43.0	243.8
File Copy 1024 bufsize 2000 maxblocks	120834.3	KBps	30.0 s	2	3960.0	305.1
File Copy 256 bufsize 500 maxblocks	36417.8	KBps	30.0 s	2	1655.0	220.0
File Copy 4096 bufsize 8000 maxblocks	290993.0	KBps	30.0 s	2	5800.0	501.7
Pipe Throughput	240124.9	lps	10.0 s	7	12440.0	193.0
Pipe-based Context Switching	21672.7	lps	10.0 s	7	4000.0	54.2
Process Creation	2885.9	lps	30.0 s	2	126.0	229.0
Shell Scripts (1 concurrent)	738.5	lpm	60.0 s	2	42.4	174.2
Shell Scripts (8 concurrent)	135.6	lpm	60.4 s	2	6.0	226.1
System Call Overhead	600176.7	lps	10.0 s	7	15000.0	400.1
System Benchmarks Index Score:						221.1

А вот тот же тест на pf-kernel (3.0-pf):

Test	Score	Unit	Time	Iters.	Baseline	Index
Dhrystone 2 using register variables	3700926.6	lps	10.0 s	7	116700.0	317.1
Double-Precision Whetstone	846.1	MWIPS	10.2 s	7	55.0	153.8
Execl Throughput	1343.2	lps	29.6 s	2	43.0	312.4
File Copy 1024 bufsize 2000 maxblocks	127468.0	KBps	30.0 s	2	3960.0	321.9
File Copy 256 bufsize 500 maxblocks	37622.9	KBps	30.0 s	2	1655.0	227.3
File Copy 4096 bufsize 8000 maxblocks	342606.2	KBps	30.0 s	2	5800.0	590.7
Pipe Throughput	296672.7	lps	10.0 s	7	12440.0	238.5
Pipe-based Context Switching	41227.5	lps	10.0 s	7	4000.0	103.1
Process Creation	3969.3	lps	30.0 s	2	126.0	315.0
Shell Scripts (1 concurrent)	861.1	lpm	60.1 s	2	42.4	203.1
Shell Scripts (8 concurrent)	159.4	lpm	60.2 s	2	6.0	265.6
System Call Overhead	642005.3	lps	10.0 s	7	15000.0	428.0
System Benchmarks Index Score:						264.6

Как видно, общий прирост производительности составил 20%.

Ubuntu

Теперь результаты этих же тестов, но у же для Ubuntu.
На стандартном ядре (2.6.38-11-generic):

Test	Score	Unit	Time	Iters.	Baseline	Index
Dhrystone 2 using register variables	39162082.2	lps	10.0 s	7	116700.0	3355.8
Double-Precision Whetstone	9143.1	MWIPS	9.9 s	7	55.0	1662.4
Execl Throughput	11472.2	lps	29.8 s	2	43.0	2668.0
File Copy 1024 bufsize 2000 maxblocks	1041722.3	KBps	30.0 s	2	3960.0	2630.6
File Copy 256 bufsize 500 maxblocks	327345.4	KBps	30.0 s	2	1655.0	1977.9
File Copy 4096 bufsize 8000 maxblocks	1730411.9	KBps	30.0 s	2	5800.0	2983.5
Pipe Throughput	4204868.3	lps	10.0 s	7	12440.0	3380.1
Pipe-based Context Switching	738528.0	lps	10.0 s	7	4000.0	1846.3
Process Creation	32309.9	lps	30.0 s	2	126.0	2564.3
Shell Scripts (1 concurrent)	11023.5	lpm	60.0 s	2	42.4	2599.9
Shell Scripts (8 concurrent)	1425.4	lpm	60.0 s	2	6.0	2375.7
System Call Overhead	5723850.3	lps	10.0 s	7	15000.0	3815.9
System Benchmarks Index Score:						2580.4

На pf ядре (2.6.38-pf8):

Test	Score	Unit	Time	Iters.	Baseline	Index
Dhrystone 2 using register variables	71269301.5	lps	10.0 s	7	116700.0	6107.1
Double-Precision Whetstone	9175.2	MWIPS	9.9 s	7	55.0	1668.2
Execl Throughput	12014.6	lps	30.0 s	2	43.0	2794.1
File Copy 1024 bufsize 2000 maxblocks	1580881.5	KBps	30.0 s	2	3960.0	3992.1
File Copy 256 bufsize 500 maxblocks	428842.2	KBps	30.0 s	2	1655.0	2591.2
File Copy 4096 bufsize 8000 maxblocks	2315055.5	KBps	30.0 s	2	5800.0	3991.5
Pipe Throughput	4389021.4	lps	10.0 s	7	12440.0	3528.2
Pipe-based Context Switching	831655.8	lps	10.0 s	7	4000.0	2079.1
Process Creation	34789.6	lps	30.0 s	2	126.0	2761.1
Shell Scripts (1 concurrent)	11890.9	lpm	60.0 s	2	42.4	2804.5
Shell Scripts (8 concurrent)	1506.4	lpm	60.0 s	2	6.0	2510.7
System Call Overhead	5815793.6	lps	10.0 s	7	15000.0	3877.2
System Benchmarks Index Score:						3050.7

Прирост составил 18%, что на мой взгляд довольно ощутимо. Почему второй тест выдал чуть меньший результат? Скорее всего, дело в том, что тест проводился на x86_64 и в стандартном ядре было больше оптимизаций под архитектуру процессора, чем при ядре собранном под Pentium Pro на Intel Atom (SSE и прочие).

Как из этого всего видно, смысл в сборке своего ядра есть. Результаты примерно одинаковые на двух довольно разных процессорах: Intel Atom N270 и Core 2 Duo E8500.

Описывать процесс установки ядра для ARCH я не буду, он максимально прост. Я уверен, что для его пользователей это не составит труда.

Сборка и установка pf-kernel для Ubuntu

Качаем ядро своей версии с kernel.org. Внимание: качать нужно версию без стабилизационных патчей (в случае с 2.6.38.11 качать нужно просто 2.6.38).
Качаем pf-kernel для этой версии ядра отсюда.
Распаковываем архивы и ставим патч.
patch -p1 < (адрес pfkernel патча)

Копируем свой конфиг в папку с ядром.
cp /boot/config-`uname -r` .config

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

make localmodconfig
если будет ругаться на то что нет /sbin/lsmod
ln -s /bin/lsmod /sbin/lsmod

Настраиваем ядро
make menuconfig
Нужно включить BFS, BFQ и tuxonice при желании, а также во вкладке о процессоре стоит выбрать оптимизацию под свой процессор.

Ставим патч для ядер с kernel.org
sed -rie 's/echo "\+"/#echo "\+"/' scripts/setlocalversion

Очищаем директорию
make-kpkg clean

Собираем
CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-pf kernel_image kernel_headers

Вот собственно и все. Ставим ядро командой dpkg -i *.deb, перезагружаемся и выбираем его в загрузчике.

UPDATE:
Zen Kernel показал практически идентичный результат, местами чуть лучше, но в общем не более чем на 5%, а затем скрашился даже не завершив все тесты (время теста около 40 минут).
Некто Mr.z очень сильно сомневался в правильности расчетов, тут в таблице видно прирост показателей по каждому тесту, а также средний прирост, а не только прирост индекса. Цифры вышли практически полностью одинаковыми.
Для IoGa,WiseLord и gnomeby — Сравнение ванильного ядра с ванильным собранным под свою архитектуру если и показало прирост производительности, то не больше уровня погрешности, разницы почти ни какой.

+65

162

NermaN 17,1 G+

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

комментарии (62)

painEffect, 26 октября 2011 в 14:42 #

> Zen Kernel я не вижу особого смысла, т.к. во-первых, проект выглядит заброшенным
git.zen-kernel.org/zen-stable/ — вовсе не заброшен

NermaN, 26 октября 2011 в 17:22 #

↵

↑

Чуть позже добавлю результаты Zen Kernel.

painEffect, 26 октября 2011 в 14:44 #

А еще есть liquorix.net с готовыми сборками Zen Kernel для debian в виде репозитория

+19

pfactum, 26 октября 2011 в 15:10 #

Хочу вдогонку сказать несколько слов.

Во-первых, zen-kernel совсем не заброшен, просто они перешли на модель релизов без выпуска патчей. Я сам от них с удовольствием периодически утаскиваю в pf-kernel, например, тот же BFQ, пока не выходят официальные патчи.

Во-вторых, настоятельно рекомендую не заморачиваться с патчами для старых ядер, так как я просто для них не выпускаю новые версии pf-kernel. Вообще, этот патчсет для любителей bleeding-edge, а исправления в старые версии не вносятся.

В-третьих, для Arch Linux есть PKGBUILD в AUR'е: aur.archlinux.org/packages.php?ID=50956

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

decanet, 26 октября 2011 в 15:35 #

Вопросы к вам:
1. Как я понял, вы девелопер pf ядер?
2. Имеет ли смысл использовать ваши ядра на серверах(предположим высоконагруженные веб сервера(apache/nginx/mysql/pgsql)).
Будет ли и там прирост производительности или вы затачиваете свои ядра под десктопы?
3. Имеет смысл использовать ваши ядра под виртуальные машины(как гость, так и хост)? Будет ли прирост производительности?

Ну это для начала.

+13

pfactum, 26 октября 2011 в 15:41 #

1. да;
2. я не имею такого опыта, пользуюсь им только на своём ноутбуке. Могу только предположить, что на процессорах с количеством ядер меньше или равно восьми попробовать стоит;
3. регулярно пользуюсь виртуальной машиной, хост — на pf-kernel, ощущения получше, чем при использовании дистрибутивных ядер.

Mecid, 26 октября 2011 в 16:04 #

А вы думаете о создании ppa для ubuntu?

+10

pfactum, 26 октября 2011 в 16:24 #

Я положительно к этому отношусь, если ppa будет заниматься кто-то, кроме меня.

Если вы — дайте знать, помещу ссылочку на сайте.

PocketSam, 27 октября 2011 в 09:40 #

Поделитесь, пожалуйста, ссылкой на свой сайт.

pfactum, 27 октября 2011 в 10:20 #

pf.natalenko.name

Eddy_Em, 27 октября 2011 в 09:44 #

post-factum, а вы сами свои патчи не тестировали?

Интересно, конечно, получается. Никогда бы не подумал, что из ядра можно выжать аж 20% повышения производительности.

pfactum, 27 октября 2011 в 10:21 #

Нет, чисел никогда не получал, только субъективные ощущения.

Wuron, 26 октября 2011 в 15:16 #

Не смотря на то что баллы отличаются на 18/20%, время в каждом из тестов отличается максимум на 0.2 секунды. Следовательно вопрос: прирост производительности ощущается только по увеличению циферок, или же система правда шустрее работает?

NermaN, 26 октября 2011 в 15:21 #

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

Psih, 26 октября 2011 в 15:57 #

Как приверженец Gentoo на серверах после всяких CentOS, Fedora и Ubuntu — сборка системы под железо и настройка ядра с использованием головы (а последнее время и genkernel весьма поумнел) скажу что эффект на современном оборудовании весьма ощутим. Многие пакеты бинарные скомпилированы так, что совместимы с весьма далёкими предками сегодняшних процессоров, а это оставляет весьма большой простор для оптимизации. К тому же на руку играет тот факт, что при установке Gentoo руки сами как-то тянутся настроить всё нормально изначально. К тому же в Gentoo не такие консервативные настройки по умолчанию, особенно в сетевой части. Опытным путём доказанно что там, где Ubuntu Server дохнет от сетевой нагрузки, заботливо собранное Gentoo ядро без особых модификаций в сетевом стеке вполне себе справляется и не уводит сервак в непонятный ступор — худо-бедно, но под 100% нагрузкой сервер отвечает и умудряется перемалывать запросы к нему. Ubuntu машина просто не отвечает и её сетевая часть просто умирает.
Всё выше сказанное чисто субъективно и личный опыт. В духе истенного Gentoo'ника скажу так — просто попробуйте сами и решите надо оно вам или нет :)

Psih, 26 октября 2011 в 16:03 #

Да, забыл дописать что Ubuntu можно вылечить перешерстив настройки сетевого стека, а так же очень желательно посмотреть настройки ядра и перекомпилить его с модификациями. Разница в том, что в Gentoo не то что проще — это стандартная часть процесса, которая не вызывает каких либо проблем.

+12

GearHead, 26 октября 2011 в 17:48 #

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

–1

Psih, 26 октября 2011 в 18:07 #

Вопрос организации рабочего времени?
Компилится себе в фоне в SSH окне и пусть компилится, тем временем делаю остальную работу. А тонкая настройка ядра и /proc/ в любом случае на любом Линуксе процесс долгий.

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

magnum, 13 ноября 2011 в 02:57 #

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

oleg_podsadny, 26 октября 2011 в 15:32 #

Если использовать виртуализацию, то для некоторых гипервизоров кастомное ядро — просто необходимость

IoGA, 26 октября 2011 в 15:44 #

Phoronix недавно тестировал отдельно BFS (т.е. -ck patchset), и увеличения в производительности замечено там не было, скорее даже снижение в ней; только автор постоянно отмечал, что отзывчивость системы в целом гораздо лучше, но это вещь совершенно эмпирическая.

Насколько я понимаю, в -pf ядре прирост должны обеспечивать именно BFS и BFQ.

Получается, что либо ваш тест не очень верен, либо phoronix врёт, либо BFQ даёт прирост в 20%, что едва ли истинно.

Либо, к примеру, конфигурация ядер отличается не только в плане этих patchset'ов.

NermaN, 26 октября 2011 в 15:46 #

Тут можно глянуть чистые отчеты UnixBench.

IoGA, 26 октября 2011 в 15:49 #

Ну, там точно те же числа, что в статье. Я не знаком с UnixBench'ем, так что принимаю его Index на веру.
Может быть этот результат нужно как-нибудь логарифмировать, так что реальный прирост будет в полпроцента?

WiseLord, 26 октября 2011 в 16:04 #

Интересно, что дало больший эффект — собственно патчи или же другие улучшения/облегчения ядра (вроде make localmodconfig).

Или всё-таки сравнение было «честное»? В смысле, сравнивалось стандартное ядро и пропатченное (и более ничего — только наложен патч + включены опции, касающиеся только патча, никаких других оптимизаций).

NermaN, 26 октября 2011 в 16:16 #

Патч + сборка под свою архитектуру + localmodconfig, но он не должен особо влиять на производительность так как почти все что он отключает это модули.

IoGA, 26 октября 2011 в 16:27 #

Гм, так тогда, видимо, львиную долю производительности даёт не patchset, а как раз сборка под личную архитектуру.
В этом случае было бы клево включить в тестирование самосборное ванильное непатченное ядро.

WiseLord, 26 октября 2011 в 16:30 #

Интересно было бы просто стандартное ядро + сборка под свою архитектуру + localmodconfig сравнить с этим ядром.

Robotex, 26 октября 2011 в 16:18 #

Не пойму, убунта в 10 раз производительнее арча? Почему общая оценка отличается на порядок? Или арч быстрее убунты в 10 раз?

IoGA, 26 октября 2011 в 16:18 #

Автор тестировал на разных машинах.

Robotex, 26 октября 2011 в 16:54 #

Тьфу. Так тогда чистота эксперимента нарушена походу.

NermaN, 26 октября 2011 в 16:56 #

Почему? Наоборот по 2 теста на 2 разных машинах с разными дистрибами, наоборот все хорошо должно быть.

Robotex, 26 октября 2011 в 17:06 #

Ну я когда открывал эту статью, надеялся параллельно сравнить арч и убунту, а тут облом.

Robotex, 26 октября 2011 в 17:08 #

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

NermaN, 26 октября 2011 в 17:14 #

Все же я писал о том, что есть ли смысл возится с ядрами для ускорения производительности, а не сравнивал убунту и арч =)

Robotex, 26 октября 2011 в 17:17 #

Ну это могло бы идти в качестве бонуса :)

Maxim_ka, 26 октября 2011 в 16:20 #

Спасибо, давно не решался попробовать, с мыслью, а оно мне надо, сейчас убедили, что для нетбука стоит попробовать. Как говорится будем посмотреть…

alexyr, 26 октября 2011 в 16:55 #

У меня сборка ядра съедает 383 гига и вылетает с ошибкой о нехватке места. Сколько ж ей надо?

NermaN, 26 октября 2011 в 16:57 #

Около 4 гигабайт хватает о_О

f0b0s, 26 октября 2011 в 17:02 #

Это странно, я на виртуалках линукс кастомный собирал, а на боевой старой машине фряшное ядро.
Максимум гигов 40 на обеих системах было. Думаю, у вас что-то течет.

Narical, 26 октября 2011 в 22:51 #

ну ок, у меня на eee pc 701 с хардом на 4 Gb все успешно собиралось… ессно, система места тоже немало съедала, вместе с gcc и прочими сопутствующими штуками

Robotex, 26 октября 2011 в 17:09 #

Сначала подумал, что вы об оперативной памяти и ужаснулся.

Сколько ядро не собирал, ни разу не заработало потом.

SergMarkov, 27 октября 2011 в 09:52 #

А не надо свой конфиг с нуля делать, подсовываем из /proc/config.gz и уже его правим
Вот тут в середине о сборке ядра на пальцах

SergMarkov, 27 октября 2011 в 10:43 #

Блин :-)
www.box.net/shared/bc84ux3c2noqy43zikhz

alexyr, 26 октября 2011 в 17:17 #

В общем, прогнал еще пару раз… перед этим запуская make clean && make-kpkg clean. Всё равно съедает всё свободное место (~390Гб) и вылетает…

NermaN, 26 октября 2011 в 17:23 #

Что конкретно занимает столько места? Может там просто какая-то ошибка.

alexyr, 26 октября 2011 в 17:42 #

Вот взгляните.

alexyr, 27 октября 2011 в 13:29 #

Так и не нашел где утечка, собрал на другом компе.
Результаты тестирования:

Было ( Ubuntu 11.04 2.6.38-12-generic ):

System Benchmarks Index Score 470.3 ( 1 процесс )
System Benchmarks Index Score 913.4 ( 2 параллельных процесса )

Стало ( Ubuntu 11.04 2.6.38-pf8 ):

System Benchmarks Index Score 585.8 ( 1 процесс )
System Benchmarks Index Score 1065.1 ( 2 параллельных процесса )

SergMarkov, 27 октября 2011 в 09:46 #

У меня есть старый duron 900 c 512 метрами и гигом свапа Так на нем при сборке ядра свап не используется :-))

gnomeby, 26 октября 2011 в 17:31 #

То есть вы тестировали стандартное ядро дистрибутива с собранным вручную? Я думаю ван нужно сравнивать ванильное ядро собранное вручную с кастомным.

NermaN, 26 октября 2011 в 17:43 #

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

alexyr, 26 октября 2011 в 17:52 #

Кстати, вот в этой статье написано:

General rule, concurrency level = number of processor cores + 1

А след. команда вроде бы выдаёт только количество процессоров:
`getconf _NPROCESSORS_ONLN`

Есть еще какие-то нюансы?

alexyr, 26 октября 2011 в 17:55 #

Извиняюсь, имел ввиду количество ядер (у меня на Core2Duo выводит 2)

ValdikSS, 26 октября 2011 в 21:10 #

При использовании BFS автор рекомендует concurrency level = number of processor cores, т.к. раньше считалось, что добавлять +1 — хороший тон, т.к. будет меньше оверхед менеджера задач. Но для BFS это не так.

–4

ananazzz, 26 октября 2011 в 18:39 #

Ололо, в Gentoo уже кто-нибудь испытал? Поделитесь результатом? Сейчас сам юзаю это: 3.0.6-gentoo #2 SMP PREEMPT Sun Oct 23 22:03:33 MSK 2011 x86_64 Intel® Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux / CFQ scheduler

SergMarkov, 26 октября 2011 в 22:53 #

В эти проценты не входит фризы при активных операциях с диском без BFQ :-)

Maxim_ka, 27 октября 2011 в 12:26 #

Как и обещал попробовал Ваш метод, все получилось, только в статейку думаю стоит добавить команду
update-initramfs -c -k 'kernel name' — в моем случае было 2.6.38-pf8-pf.
Собирал на нетбуке ASUS 1005HA(Atom 1,6N280, 1Gb RAM), на сборку deb пакета примерно ушло 1,5 часа.

spyfzm, 27 октября 2011 в 23:26 #

Проблематика: с kernel.org скачан linux-3.0.4.tar.gz, с pf.natalenko.name/sources/ скачан patch-3.0.4-pf.bz2, патчу, происходит непонятное: Reversed (or previously applied) patch detected! Assume -R? [n].
Насколько я понимаю, это происходит, если патчится исходник, уже пропатченный чем-то другим, имеющий стабилизационные патчи или что-то в этом духе. Но этот патч вроде бы именно для этих исходников. Подскажите, что делать, гугл внятных ответов на запрос по этой фразе не дает…

kion, 27 октября 2011 в 23:55 #

Там же ясно сказано:

> Latest patch 3.0.7-pf * (20.10.2011), applies to bare 3.0 kernel with no stable patches

Тоесть, качаем 3.0 kernel with no stable patches, затем patch 3.0.7-pf и следуем указанным инструкциям.

kion, 27 октября 2011 в 23:57 #

Кстати, у меня на Ubuntu 11.10 (с использованием указанных мною выше версий ядра/патча) собралось без проблем.

kion, 28 октября 2011 в 04:42 #

В общем, на моей рабочей станции (i5-2500K / 8GB RAM) данное кастомное ядро показало неоднозначные результаты: бенчмарк в однопоточном режиме показал прирост производительности, в многопоточном (х4) — наоборот (хоть падение производительности и не столь существенно).

Результаты UnixBench для ядра «из коробки» (3.0.0-13-generic-pae)

------------------------------------------------------------------------
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       24954918.0 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     3331.3 MWIPS (10.0 s, 7 samples)
Execl Throughput                               2008.1 lps   (29.7 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        805234.2 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          218992.6 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       2151942.7 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1235692.0 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  85006.2 lps   (10.0 s, 7 samples)
Process Creation                               7386.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   4869.6 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   2791.1 lpm   (60.0 s, 2 samples)
System Call Overhead                        3104694.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   24954918.0   2138.4
Double-Precision Whetstone                       55.0       3331.3    605.7
Execl Throughput                                 43.0       2008.1    467.0
File Copy 1024 bufsize 2000 maxblocks          3960.0     805234.2   2033.4
File Copy 256 bufsize 500 maxblocks            1655.0     218992.6   1323.2
File Copy 4096 bufsize 8000 maxblocks          5800.0    2151942.7   3710.2
Pipe Throughput                               12440.0    1235692.0    993.3
Pipe-based Context Switching                   4000.0      85006.2    212.5
Process Creation                                126.0       7386.9    586.3
Shell Scripts (1 concurrent)                     42.4       4869.6   1148.5
Shell Scripts (8 concurrent)                      6.0       2791.1   4651.9
System Call Overhead                          15000.0    3104694.8   2069.8
                                                                   ========
System Benchmarks Index Score                                        1192.4

------------------------------------------------------------------------
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables      102716188.6 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    14603.9 MWIPS (10.1 s, 7 samples)
Execl Throughput                              17386.1 lps   (29.7 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks       1152095.1 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          305567.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       3405913.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                             5110549.2 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 996596.3 lps   (10.0 s, 7 samples)
Process Creation                              57144.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                  25365.6 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   3370.5 lpm   (60.0 s, 2 samples)
System Call Overhead                        9628991.9 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0  102716188.6   8801.7
Double-Precision Whetstone                       55.0      14603.9   2655.3
Execl Throughput                                 43.0      17386.1   4043.3
File Copy 1024 bufsize 2000 maxblocks          3960.0    1152095.1   2909.3
File Copy 256 bufsize 500 maxblocks            1655.0     305567.5   1846.3
File Copy 4096 bufsize 8000 maxblocks          5800.0    3405913.0   5872.3
Pipe Throughput                               12440.0    5110549.2   4108.2
Pipe-based Context Switching                   4000.0     996596.3   2491.5
Process Creation                                126.0      57144.9   4535.3
Shell Scripts (1 concurrent)                     42.4      25365.6   5982.4
Shell Scripts (8 concurrent)                      6.0       3370.5   5617.5
System Call Overhead                          15000.0    9628991.9   6419.3
                                                                   ========
System Benchmarks Index Score                                        4196.7

Результаты UnixBench для кастомного ядра (3.0.7-pf-pf)

------------------------------------------------------------------------
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       24795931.6 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     3319.8 MWIPS (10.0 s, 7 samples)
Execl Throughput                               5026.2 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        839112.4 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          224747.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       2296879.1 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1248804.7 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 190032.9 lps   (10.0 s, 7 samples)
Process Creation                               8296.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   5330.4 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   3167.4 lpm   (60.0 s, 2 samples)
System Call Overhead                        3226740.5 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   24795931.6   2124.8
Double-Precision Whetstone                       55.0       3319.8    603.6
Execl Throughput                                 43.0       5026.2   1168.9
File Copy 1024 bufsize 2000 maxblocks          3960.0     839112.4   2119.0
File Copy 256 bufsize 500 maxblocks            1655.0     224747.5   1358.0
File Copy 4096 bufsize 8000 maxblocks          5800.0    2296879.1   3960.1
Pipe Throughput                               12440.0    1248804.7   1003.9
Pipe-based Context Switching                   4000.0     190032.9    475.1
Process Creation                                126.0       8296.9    658.5
Shell Scripts (1 concurrent)                     42.4       5330.4   1257.2
Shell Scripts (8 concurrent)                      6.0       3167.4   5279.0
System Call Overhead                          15000.0    3226740.5   2151.2
                                                                   ========
System Benchmarks Index Score                                        1435.5

------------------------------------------------------------------------
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       89324365.7 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    13382.8 MWIPS (10.1 s, 7 samples)
Execl Throughput                              18250.0 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks       1208805.9 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          295706.4 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       3626687.1 KBps  (30.0 s, 2 samples)
Pipe Throughput                             4618032.1 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 530141.2 lps   (10.0 s, 7 samples)
Process Creation                              60903.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                  27508.6 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   3394.0 lpm   (60.0 s, 2 samples)
System Call Overhead                        9095238.0 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   89324365.7   7654.2
Double-Precision Whetstone                       55.0      13382.8   2433.2
Execl Throughput                                 43.0      18250.0   4244.2
File Copy 1024 bufsize 2000 maxblocks          3960.0    1208805.9   3052.5
File Copy 256 bufsize 500 maxblocks            1655.0     295706.4   1786.7
File Copy 4096 bufsize 8000 maxblocks          5800.0    3626687.1   6252.9
Pipe Throughput                               12440.0    4618032.1   3712.2
Pipe-based Context Switching                   4000.0     530141.2   1325.4
Process Creation                                126.0      60903.9   4833.6
Shell Scripts (1 concurrent)                     42.4      27508.6   6487.9
Shell Scripts (8 concurrent)                      6.0       3394.0   5656.7
System Call Overhead                          15000.0    9095238.0   6063.5
                                                                   ========
System Benchmarks Index Score                                        3946.3

eexo, 28 октября 2011 в 11:52 #

Dual Xeon X5550, 10G RAM

2.6.39 без pf:
— 16 CPUs in system; running 16 parallel copies of tests:
System Benchmarks Index Score 1125.5

16 CPUs in system; running 16 parallel copies of tests:
System Benchmarks Index Score 5562.7

2.6.39-pf4-pf
— 16 CPUs in system; running 16 parallel copies of tests:
System Benchmarks Index Score 1030.6

16 CPUs in system; running 16 parallel copies of tests:
System Benchmarks Index Score 3781.8

Тестовая задача (сборка сервера mysql) идет в 4 раза медленее с патчем чем без него.

eexo, 28 октября 2011 в 11:56 #

опс, index score ~1000 — это для однопоточных тестов.