Comments 62
> Zen Kernel я не вижу особого смысла, т.к. во-первых, проект выглядит заброшенным
git.zen-kernel.org/zen-stable/ — вовсе не заброшен
git.zen-kernel.org/zen-stable/ — вовсе не заброшен
А еще есть liquorix.net с готовыми сборками Zen Kernel для debian в виде репозитория
Хочу вдогонку сказать несколько слов.
Во-первых, zen-kernel совсем не заброшен, просто они перешли на модель релизов без выпуска патчей. Я сам от них с удовольствием периодически утаскиваю в pf-kernel, например, тот же BFQ, пока не выходят официальные патчи.
Во-вторых, настоятельно рекомендую не заморачиваться с патчами для старых ядер, так как я просто для них не выпускаю новые версии pf-kernel. Вообще, этот патчсет для любителей bleeding-edge, а исправления в старые версии не вносятся.
В-третьих, для Arch Linux есть PKGBUILD в AUR'е: aur.archlinux.org/packages.php?ID=50956
Ну и напоследок, конечно же, спасибо за тесты. Теперь буду ссылаться на статью, когда меня будут спрашивать, зачем я это делаю.
Во-первых, zen-kernel совсем не заброшен, просто они перешли на модель релизов без выпуска патчей. Я сам от них с удовольствием периодически утаскиваю в pf-kernel, например, тот же BFQ, пока не выходят официальные патчи.
Во-вторых, настоятельно рекомендую не заморачиваться с патчами для старых ядер, так как я просто для них не выпускаю новые версии pf-kernel. Вообще, этот патчсет для любителей bleeding-edge, а исправления в старые версии не вносятся.
В-третьих, для Arch Linux есть PKGBUILD в AUR'е: aur.archlinux.org/packages.php?ID=50956
Ну и напоследок, конечно же, спасибо за тесты. Теперь буду ссылаться на статью, когда меня будут спрашивать, зачем я это делаю.
Вопросы к вам:
1. Как я понял, вы девелопер pf ядер?
2. Имеет ли смысл использовать ваши ядра на серверах(предположим высоконагруженные веб сервера(apache/nginx/mysql/pgsql)).
Будет ли и там прирост производительности или вы затачиваете свои ядра под десктопы?
3. Имеет смысл использовать ваши ядра под виртуальные машины(как гость, так и хост)? Будет ли прирост производительности?
Ну это для начала.
1. Как я понял, вы девелопер pf ядер?
2. Имеет ли смысл использовать ваши ядра на серверах(предположим высоконагруженные веб сервера(apache/nginx/mysql/pgsql)).
Будет ли и там прирост производительности или вы затачиваете свои ядра под десктопы?
3. Имеет смысл использовать ваши ядра под виртуальные машины(как гость, так и хост)? Будет ли прирост производительности?
Ну это для начала.
1. да;
2. я не имею такого опыта, пользуюсь им только на своём ноутбуке. Могу только предположить, что на процессорах с количеством ядер меньше или равно восьми попробовать стоит;
3. регулярно пользуюсь виртуальной машиной, хост — на pf-kernel, ощущения получше, чем при использовании дистрибутивных ядер.
2. я не имею такого опыта, пользуюсь им только на своём ноутбуке. Могу только предположить, что на процессорах с количеством ядер меньше или равно восьми попробовать стоит;
3. регулярно пользуюсь виртуальной машиной, хост — на pf-kernel, ощущения получше, чем при использовании дистрибутивных ядер.
А вы думаете о создании ppa для ubuntu?
post-factum, а вы сами свои патчи не тестировали?
Интересно, конечно, получается. Никогда бы не подумал, что из ядра можно выжать аж 20% повышения производительности.
Интересно, конечно, получается. Никогда бы не подумал, что из ядра можно выжать аж 20% повышения производительности.
Не смотря на то что баллы отличаются на 18/20%, время в каждом из тестов отличается максимум на 0.2 секунды. Следовательно вопрос: прирост производительности ощущается только по увеличению циферок, или же система правда шустрее работает?
На нетбуке разницу я смог ощутить, на десктопе все и без того быстро работало.
Как приверженец Gentoo на серверах после всяких CentOS, Fedora и Ubuntu — сборка системы под железо и настройка ядра с использованием головы (а последнее время и genkernel весьма поумнел) скажу что эффект на современном оборудовании весьма ощутим. Многие пакеты бинарные скомпилированы так, что совместимы с весьма далёкими предками сегодняшних процессоров, а это оставляет весьма большой простор для оптимизации. К тому же на руку играет тот факт, что при установке Gentoo руки сами как-то тянутся настроить всё нормально изначально. К тому же в Gentoo не такие консервативные настройки по умолчанию, особенно в сетевой части. Опытным путём доказанно что там, где Ubuntu Server дохнет от сетевой нагрузки, заботливо собранное Gentoo ядро без особых модификаций в сетевом стеке вполне себе справляется и не уводит сервак в непонятный ступор — худо-бедно, но под 100% нагрузкой сервер отвечает и умудряется перемалывать запросы к нему. Ubuntu машина просто не отвечает и её сетевая часть просто умирает.
Всё выше сказанное чисто субъективно и личный опыт. В духе истенного Gentoo'ника скажу так — просто попробуйте сами и решите надо оно вам или нет :)
Всё выше сказанное чисто субъективно и личный опыт. В духе истенного Gentoo'ника скажу так — просто попробуйте сами и решите надо оно вам или нет :)
Да, забыл дописать что Ubuntu можно вылечить перешерстив настройки сетевого стека, а так же очень желательно посмотреть настройки ядра и перекомпилить его с модификациями. Разница в том, что в Gentoo не то что проще — это стандартная часть процесса, которая не вызывает каких либо проблем.
как человек, пересевший с Gentoo на Ubuntu, я хочу заметить, что рабочее время тоже стоит денег. и деньги, сэкономленные на оборудовании вы сливаете тратой времени на сборку системы.
Вопрос организации рабочего времени?
Компилится себе в фоне в SSH окне и пусть компилится, тем временем делаю остальную работу. А тонкая настройка ядра и /proc/ в любом случае на любом Линуксе процесс долгий.
К тому же компилится и обновляется всё не так уж часто. Это по началу с непривычки может занять долго, а когда уже со всем знаком, то занимает это всё ничуть не дольше чем на любом бинарном дистре. А хороший админ вообще подымет локальный portage сервер и будет с него раздавать уже скомпиленные и проверенные пакеты на свою инфраструктуру.
Компилится себе в фоне в SSH окне и пусть компилится, тем временем делаю остальную работу. А тонкая настройка ядра и /proc/ в любом случае на любом Линуксе процесс долгий.
К тому же компилится и обновляется всё не так уж часто. Это по началу с непривычки может занять долго, а когда уже со всем знаком, то занимает это всё ничуть не дольше чем на любом бинарном дистре. А хороший админ вообще подымет локальный portage сервер и будет с него раздавать уже скомпиленные и проверенные пакеты на свою инфраструктуру.
как человек, который использует и то и другое — скажу, там где это оправдано — надо использовать то, что оправдано.
к тому же не мешает потратить часик и написать самостоятельную установку генты со всем необходимым. автоматизация рулит и педалит.
пилить бубунту до вменяемого состояния дольше, чем автоматизировать установку генты на сервер.
к тому же не мешает потратить часик и написать самостоятельную установку генты со всем необходимым. автоматизация рулит и педалит.
пилить бубунту до вменяемого состояния дольше, чем автоматизировать установку генты на сервер.
Если использовать виртуализацию, то для некоторых гипервизоров кастомное ядро — просто необходимость
Phoronix недавно тестировал отдельно BFS (т.е. -ck patchset), и увеличения в производительности замечено там не было, скорее даже снижение в ней; только автор постоянно отмечал, что отзывчивость системы в целом гораздо лучше, но это вещь совершенно эмпирическая.
Насколько я понимаю, в -pf ядре прирост должны обеспечивать именно BFS и BFQ.
Получается, что либо ваш тест не очень верен, либо phoronix врёт, либо BFQ даёт прирост в 20%, что едва ли истинно.
Либо, к примеру, конфигурация ядер отличается не только в плане этих patchset'ов.
Насколько я понимаю, в -pf ядре прирост должны обеспечивать именно BFS и BFQ.
Получается, что либо ваш тест не очень верен, либо phoronix врёт, либо BFQ даёт прирост в 20%, что едва ли истинно.
Либо, к примеру, конфигурация ядер отличается не только в плане этих patchset'ов.
Тут можно глянуть чистые отчеты UnixBench.
Интересно, что дало больший эффект — собственно патчи или же другие улучшения/облегчения ядра (вроде make localmodconfig).
Или всё-таки сравнение было «честное»? В смысле, сравнивалось стандартное ядро и пропатченное (и более ничего — только наложен патч + включены опции, касающиеся только патча, никаких других оптимизаций).
Или всё-таки сравнение было «честное»? В смысле, сравнивалось стандартное ядро и пропатченное (и более ничего — только наложен патч + включены опции, касающиеся только патча, никаких других оптимизаций).
Патч + сборка под свою архитектуру + localmodconfig, но он не должен особо влиять на производительность так как почти все что он отключает это модули.
Гм, так тогда, видимо, львиную долю производительности даёт не patchset, а как раз сборка под личную архитектуру.
В этом случае было бы клево включить в тестирование самосборное ванильное непатченное ядро.
В этом случае было бы клево включить в тестирование самосборное ванильное непатченное ядро.
Интересно было бы просто стандартное ядро + сборка под свою архитектуру + localmodconfig сравнить с этим ядром.
UFO just landed and posted this here
Спасибо, давно не решался попробовать, с мыслью, а оно мне надо, сейчас убедили, что для нетбука стоит попробовать. Как говорится будем посмотреть…
У меня сборка ядра съедает 383 гига и вылетает с ошибкой о нехватке места. Сколько ж ей надо?
Около 4 гигабайт хватает о_О
Это странно, я на виртуалках линукс кастомный собирал, а на боевой старой машине фряшное ядро.
Максимум гигов 40 на обеих системах было. Думаю, у вас что-то течет.
Максимум гигов 40 на обеих системах было. Думаю, у вас что-то течет.
UFO just landed and posted this here
В общем, прогнал еще пару раз… перед этим запуская make clean && make-kpkg clean. Всё равно съедает всё свободное место (~390Гб) и вылетает…
Что конкретно занимает столько места? Может там просто какая-то ошибка.
Вот взгляните.
Так и не нашел где утечка, собрал на другом компе.
Результаты тестирования:
Было ( 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 параллельных процесса )
Результаты тестирования:
Было ( 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 параллельных процесса )
У меня есть старый duron 900 c 512 метрами и гигом свапа Так на нем при сборке ядра свап не используется :-))
То есть вы тестировали стандартное ядро дистрибутива с собранным вручную? Я думаю ван нужно сравнивать ванильное ядро собранное вручную с кастомным.
Кстати, вот в этой статье написано:
А след. команда вроде бы выдаёт только количество процессоров:
Есть еще какие-то нюансы?
General rule, concurrency level = number of processor cores + 1
А след. команда вроде бы выдаёт только количество процессоров:
`getconf _NPROCESSORS_ONLN`Есть еще какие-то нюансы?
Ололо, в 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
В эти проценты не входит фризы при активных операциях с диском без BFQ :-)
Как и обещал попробовал Ваш метод, все получилось, только в статейку думаю стоит добавить команду
Собирал на нетбуке ASUS 1005HA(Atom 1,6N280, 1Gb RAM), на сборку deb пакета примерно ушло 1,5 часа.
update-initramfs -c -k 'kernel name' — в моем случае было 2.6.38-pf8-pf.Собирал на нетбуке ASUS 1005HA(Atom 1,6N280, 1Gb RAM), на сборку deb пакета примерно ушло 1,5 часа.
Проблематика: с 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].
Насколько я понимаю, это происходит, если патчится исходник, уже пропатченный чем-то другим, имеющий стабилизационные патчи или что-то в этом духе. Но этот патч вроде бы именно для этих исходников. Подскажите, что делать, гугл внятных ответов на запрос по этой фразе не дает…
Насколько я понимаю, это происходит, если патчится исходник, уже пропатченный чем-то другим, имеющий стабилизационные патчи или что-то в этом духе. Но этот патч вроде бы именно для этих исходников. Подскажите, что делать, гугл внятных ответов на запрос по этой фразе не дает…
Там же ясно сказано:
> 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 и следуем указанным инструкциям.
> 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 и следуем указанным инструкциям.
В общем, на моей рабочей станции (i5-2500K / 8GB RAM) данное кастомное ядро показало неоднозначные результаты: бенчмарк в однопоточном режиме показал прирост производительности, в многопоточном (х4) — наоборот (хоть падение производительности и не столь существенно).
Результаты UnixBench для ядра «из коробки» (3.0.0-13-generic-pae)
Результаты UnixBench для кастомного ядра (3.0.7-pf-pf)
Результаты 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
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 раза медленее с патчем чем без него.
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 раза медленее с патчем чем без него.
Sign up to leave a comment.
Есть ли польза от кастомных ядер