Пользователь
0,0
рейтинг
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 — Сравнение ванильного ядра с ванильным собранным под свою архитектуру если и показало прирост производительности, то не больше уровня погрешности, разницы почти ни какой.
Анатолий @NermaN
карма
40,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

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

  • +3
    > Zen Kernel я не вижу особого смысла, т.к. во-первых, проект выглядит заброшенным
    git.zen-kernel.org/zen-stable/ — вовсе не заброшен
    • +1
      Чуть позже добавлю результаты Zen Kernel.
  • +6
    А еще есть liquorix.net с готовыми сборками Zen Kernel для debian в виде репозитория
  • +19
    Хочу вдогонку сказать несколько слов.

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

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

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

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

      Ну это для начала.
      • +13
        1. да;
        2. я не имею такого опыта, пользуюсь им только на своём ноутбуке. Могу только предположить, что на процессорах с количеством ядер меньше или равно восьми попробовать стоит;
        3. регулярно пользуюсь виртуальной машиной, хост — на pf-kernel, ощущения получше, чем при использовании дистрибутивных ядер.
    • 0
      А вы думаете о создании ppa для ubuntu?
      • +10
        Я положительно к этому отношусь, если ppa будет заниматься кто-то, кроме меня.

        Если вы — дайте знать, помещу ссылочку на сайте.
        • 0
          Поделитесь, пожалуйста, ссылкой на свой сайт.
          • 0
            pf.natalenko.name
    • 0
      post-factum, а вы сами свои патчи не тестировали?

      Интересно, конечно, получается. Никогда бы не подумал, что из ядра можно выжать аж 20% повышения производительности.
      • 0
        Нет, чисел никогда не получал, только субъективные ощущения.
  • +4
    Не смотря на то что баллы отличаются на 18/20%, время в каждом из тестов отличается максимум на 0.2 секунды. Следовательно вопрос: прирост производительности ощущается только по увеличению циферок, или же система правда шустрее работает?
    • +1
      На нетбуке разницу я смог ощутить, на десктопе все и без того быстро работало.
    • +8
      Как приверженец Gentoo на серверах после всяких CentOS, Fedora и Ubuntu — сборка системы под железо и настройка ядра с использованием головы (а последнее время и genkernel весьма поумнел) скажу что эффект на современном оборудовании весьма ощутим. Многие пакеты бинарные скомпилированы так, что совместимы с весьма далёкими предками сегодняшних процессоров, а это оставляет весьма большой простор для оптимизации. К тому же на руку играет тот факт, что при установке Gentoo руки сами как-то тянутся настроить всё нормально изначально. К тому же в Gentoo не такие консервативные настройки по умолчанию, особенно в сетевой части. Опытным путём доказанно что там, где Ubuntu Server дохнет от сетевой нагрузки, заботливо собранное Gentoo ядро без особых модификаций в сетевом стеке вполне себе справляется и не уводит сервак в непонятный ступор — худо-бедно, но под 100% нагрузкой сервер отвечает и умудряется перемалывать запросы к нему. Ubuntu машина просто не отвечает и её сетевая часть просто умирает.
      Всё выше сказанное чисто субъективно и личный опыт. В духе истенного Gentoo'ника скажу так — просто попробуйте сами и решите надо оно вам или нет :)
      • 0
        Да, забыл дописать что Ubuntu можно вылечить перешерстив настройки сетевого стека, а так же очень желательно посмотреть настройки ядра и перекомпилить его с модификациями. Разница в том, что в Gentoo не то что проще — это стандартная часть процесса, которая не вызывает каких либо проблем.
        • +12
          как человек, пересевший с Gentoo на Ubuntu, я хочу заметить, что рабочее время тоже стоит денег. и деньги, сэкономленные на оборудовании вы сливаете тратой времени на сборку системы.
          • –1
            Вопрос организации рабочего времени?
            Компилится себе в фоне в SSH окне и пусть компилится, тем временем делаю остальную работу. А тонкая настройка ядра и /proc/ в любом случае на любом Линуксе процесс долгий.

            К тому же компилится и обновляется всё не так уж часто. Это по началу с непривычки может занять долго, а когда уже со всем знаком, то занимает это всё ничуть не дольше чем на любом бинарном дистре. А хороший админ вообще подымет локальный portage сервер и будет с него раздавать уже скомпиленные и проверенные пакеты на свою инфраструктуру.
          • 0
            как человек, который использует и то и другое — скажу, там где это оправдано — надо использовать то, что оправдано.
            к тому же не мешает потратить часик и написать самостоятельную установку генты со всем необходимым. автоматизация рулит и педалит.
            пилить бубунту до вменяемого состояния дольше, чем автоматизировать установку генты на сервер.
  • 0
    Если использовать виртуализацию, то для некоторых гипервизоров кастомное ядро — просто необходимость
  • 0
    Phoronix недавно тестировал отдельно BFS (т.е. -ck patchset), и увеличения в производительности замечено там не было, скорее даже снижение в ней; только автор постоянно отмечал, что отзывчивость системы в целом гораздо лучше, но это вещь совершенно эмпирическая.

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

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

    Либо, к примеру, конфигурация ядер отличается не только в плане этих patchset'ов.
    • +1
      Тут можно глянуть чистые отчеты UnixBench.
      • 0
        Ну, там точно те же числа, что в статье. Я не знаком с UnixBench'ем, так что принимаю его Index на веру.
        Может быть этот результат нужно как-нибудь логарифмировать, так что реальный прирост будет в полпроцента?
  • +1
    Интересно, что дало больший эффект — собственно патчи или же другие улучшения/облегчения ядра (вроде make localmodconfig).

    Или всё-таки сравнение было «честное»? В смысле, сравнивалось стандартное ядро и пропатченное (и более ничего — только наложен патч + включены опции, касающиеся только патча, никаких других оптимизаций).
    • 0
      Патч + сборка под свою архитектуру + localmodconfig, но он не должен особо влиять на производительность так как почти все что он отключает это модули.
      • +5
        Гм, так тогда, видимо, львиную долю производительности даёт не patchset, а как раз сборка под личную архитектуру.
        В этом случае было бы клево включить в тестирование самосборное ванильное непатченное ядро.
      • +1
        Интересно было бы просто стандартное ядро + сборка под свою архитектуру + localmodconfig сравнить с этим ядром.
  • –1
    Не пойму, убунта в 10 раз производительнее арча? Почему общая оценка отличается на порядок? Или арч быстрее убунты в 10 раз?
    • +1
      Автор тестировал на разных машинах.
      • 0
        Тьфу. Так тогда чистота эксперимента нарушена походу.
        • +1
          Почему? Наоборот по 2 теста на 2 разных машинах с разными дистрибами, наоборот все хорошо должно быть.
          • +4
            Ну я когда открывал эту статью, надеялся параллельно сравнить арч и убунту, а тут облом.
          • +1
            Ну вот на одной машине кастомное ядро дает 20% прироста, а на другой 18, что вполне может быть обусловлено разницей железа, архитектур или не пойми чего.
            • +1
              Все же я писал о том, что есть ли смысл возится с ядрами для ускорения производительности, а не сравнивал убунту и арч =)
              • 0
                Ну это могло бы идти в качестве бонуса :)
  • 0
    Спасибо, давно не решался попробовать, с мыслью, а оно мне надо, сейчас убедили, что для нетбука стоит попробовать. Как говорится будем посмотреть…
  • 0
    У меня сборка ядра съедает 383 гига и вылетает с ошибкой о нехватке места. Сколько ж ей надо?
    • +1
      Около 4 гигабайт хватает о_О
    • 0
      Это странно, я на виртуалках линукс кастомный собирал, а на боевой старой машине фряшное ядро.
      Максимум гигов 40 на обеих системах было. Думаю, у вас что-то течет.
      • 0
        ну ок, у меня на eee pc 701 с хардом на 4 Gb все успешно собиралось… ессно, система места тоже немало съедала, вместе с gcc и прочими сопутствующими штуками
    • 0
      Сначала подумал, что вы об оперативной памяти и ужаснулся.

      Сколько ядро не собирал, ни разу не заработало потом.
      • 0
        А не надо свой конфиг с нуля делать, подсовываем из /proc/config.gz и уже его правим
        Вот тут в середине о сборке ядра на пальцах
      • 0
    • 0
      В общем, прогнал еще пару раз… перед этим запуская make clean && make-kpkg clean. Всё равно съедает всё свободное место (~390Гб) и вылетает…
      • 0
        Что конкретно занимает столько места? Может там просто какая-то ошибка.
        • 0
          Вот взгляните.
          • 0
            Так и не нашел где утечка, собрал на другом компе.
            Результаты тестирования:

            Было ( 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 параллельных процесса )
    • 0
      У меня есть старый duron 900 c 512 метрами и гигом свапа Так на нем при сборке ядра свап не используется :-))
  • 0
    То есть вы тестировали стандартное ядро дистрибутива с собранным вручную? Я думаю ван нужно сравнивать ванильное ядро собранное вручную с кастомным.
    • 0
      Все же мне кажется тогда бы тесты на x86_64 не дали особого прироста. В любом случае я прямо сейчас решил сравнить ванильное ядро с ванильным с оптимизацией.
  • 0
    Кстати, вот в этой статье написано:
    General rule, concurrency level = number of processor cores + 1


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

    Есть еще какие-то нюансы?
    • 0
      Извиняюсь, имел ввиду количество ядер (у меня на Core2Duo выводит 2)
      • +1
        При использовании BFS автор рекомендует concurrency level = number of processor cores, т.к. раньше считалось, что добавлять +1 — хороший тон, т.к. будет меньше оверхед менеджера задач. Но для BFS это не так.
  • –4
    Ололо, в 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
  • 0
    В эти проценты не входит фризы при активных операциях с диском без BFQ :-)
  • 0
    Как и обещал попробовал Ваш метод, все получилось, только в статейку думаю стоит добавить команду
    update-initramfs -c -k 'kernel name' — в моем случае было 2.6.38-pf8-pf.
    Собирал на нетбуке ASUS 1005HA(Atom 1,6N280, 1Gb RAM), на сборку deb пакета примерно ушло 1,5 часа.
  • 0
    Проблематика: с 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].
    Насколько я понимаю, это происходит, если патчится исходник, уже пропатченный чем-то другим, имеющий стабилизационные патчи или что-то в этом духе. Но этот патч вроде бы именно для этих исходников. Подскажите, что делать, гугл внятных ответов на запрос по этой фразе не дает…
    • 0
      Там же ясно сказано:

      > 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 и следуем указанным инструкциям.
      • 0
        Кстати, у меня на Ubuntu 11.10 (с использованием указанных мною выше версий ядра/патча) собралось без проблем.
  • 0
    В общем, на моей рабочей станции (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
    

  • 0
    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 раза медленее с патчем чем без него.
    • 0
      опс, index score ~1000 — это для однопоточных тестов.

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