Пример компиляции ядра в таких дистрибутивах как Debian и Ubuntu с целью задействования всех возможных оптимизаций для текущего процессора (core-duo). Все произведённые действия подойдут для ubuntu 9.10 - 10.10Для начала загрузим исходные тексты ядра и заголовочные файлы:
sudo aptitude install linux-source-2.6 linux-headers
Установим утилиты для компиляции ядра
sudo aptitude install build-essential kernel-package libncurses-dev
Полученное ядро нужно распаковать:
cd /usr/src/
sudo tar -xjf linux-source-*Затем нужно выставить опции компиляции для gcc c оптимизацией под нужный процессор. Для Intel-процессоров опции можно найти на [[http://en.gentoo-wiki.com/wiki/Safe_Cflags/Intel данной странице]]. Так же начиная с GCC версии 4.2 можно указать опцию "-march=native", тогда GCC автоматически определит оптимальные настройки для вашего процессора. Так давайте же и мы воспользуемся этой замечательной возможностью. Так же рекомендуется добавлять опции "-pipe -fomit-frame-pointer".
В итоге вот какие опции у нас получаются:
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}""CFLAGS" - опции для С программ
"CXXFLAGS" - опции для C++ программ
"-march" - архитектура процессора (в нашем случае определяется автоматически)
"-O2" - это средняя оптимизация кода - компромис между быстродействием и объемом получаемого исполняемого файла (00, 01 - отсутствие оптимизации и маленькая оптимизация, маленький размер исполняемого файла, 03 - жёсткая оптимизация, большой размер исполняемого файла) Вообще не факт, что с оптимизацией 03 везде будет работать быстрее, большой размер получаемой в итоге программы ставит повышенные требования к быстродействию подсистемы памяти.Это переменные окружения, и что бы они сохранились в системе после перезагрузки надо их поместить в .bashrc файл пользователя, который будет компилировать. Я помещаю их в .bashrc своего пользователя и root, на случай если мне вздумается компилировать от рута. В конец .bashrc этих пользователей добавляем:
export CHOST="i686-pc-linux-gnu"
export CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"
export CXXFLAGS="${CFLAGS}"Для вступления в силу изменений надо заново зайти пользователем, так как компиляция будет происходить в консоли, и в GUI нам эти параметры не нужны, достаточно просто открыть новую консоль.
Теперь все программы, которые мы будем компилировать, будут оптимизированы согласно этим опциям. Теперь можно переходить непосредственно к компиляции ядра.
Все операции с ядром производятся в корне директории с исходными текстами ядра, поэтому недолго думая переходим туда:
cd /usr/src/linux-source-*
Создадим файл конфигурации текущего ядра командой
sudo make oldconfig
Эта команда создаст файл .config, где будут указаны опции ядра, используемого в данной системе. Эти настройки будут основой для наших настроек. Приступим к конфигурации ядра:
sudo make menuconfig
С помощью этой утилиты указываем необходимые нам опции.
Обращаю ваше внимание на следующую опцию:Processor type and features ---> Processor family
Здесь выбираем свой процессор. Остальные опции, которые мы взяли из ядра идущего с дистрибутивом вполне работоспособны для большинства применений, поэтому изменяйте их по своему усмотрению, или оставляйте как есть.
Далее, выполним команду, которая удалит файлы (если они имеются), оставшиеся от предыдущей компиляции:
sudo make-kpkg clean
Далее компилируем ядро командой:
sudo nice -n 19 make-kpkg --initrd --append-to-version=-mykernel kernel_image kernel_headers
"nice -n 19" понизит приоритет компиляции на 19 пунктов
Ключ "-append-to-version" используется, чтобы добавить к имени файла образа ядра, который мы получим после компиляции, строку "-mykernel", чтобы было проще идентифицировать свое ядро.И, через несколько минут/часов или может у кого то и дней, мы получим оптимизированное для нашей архитектуры ядро. На Celeron 3.06GHz это заняло два с половиной часа.
Если всё пройдёт удачно, в итоге в /usr/src/ получим два deb-пакета linux-headers-*.deb и linux-image-*.deb, которые следует установить в систему:
sudo dpkg -i linux-headers-*.deb linux-image-*.deb
Установщик так же обновит конфигурацию grub и поставит новое ядро во главе списка. Теперь можно перезагрузить в систему с новым ядром!
URL: http://www.comeinadmin.ru/article/compile-kernel-linux.html
Обсуждается: http://www.opennet.me/tips/info/2549.shtml
Почему-то решил, что в статье описан процесс кросс-компиляции ядра для всяких армов и мипселей.
Был разочарован :)
А накой вам?
> А накой вам?Дык это, натой чтобы закомпилить свой кернель под такую железяку. Благо их как грязи развелось таких, армовских и мипсовых. И недорогие. И мелкие. Вплот до штук со спичечный коробок размерами, и при том - полноценный комп с линухом по сути. Это ж прикольно, а? :)
>> А накой вам?
> Дык это, натой чтобы закомпилить свой кернель под такую железяку. Благо их
> как грязи развелось таких, армовских и мипсовых. И недорогие. И мелкие.
> Вплот до штук со спичечный коробок размерами, и при том -
> полноценный комп с линухом по сути. Это ж прикольно, а? :)Я собственна о том, что покупая МИПС/АРМ уже надо знать шо таке кросс-компиляция
А какие-нибудь performance тесты не проводили? Есть ли какой-нибудь реальный смысл во всем этом?
> А какие-нибудь performance тесты не проводили? Есть ли какой-нибудь реальный смысл во
> всем этом?Тесты не проводились, в интернете о подобных тестах ничего нет. Я раньше на Gentoo сидел, там можно было всю систему так откомпилировать, но там в репозитории пакеты нестабильные, и частенько что нибудь падало, и я пересел на дебиан, а теперь вот на ubuntu, но в этих дистрибах ничего подобного нет, с apt-build-ом у меня не сложилось, и судя по отзывам ни у кого он нормально не работает, а в заднице свербило, ведь в gcc можно указать отпции компиляции под процессор, а ubuntu и debian пакеты компиляются с опцией i386 или в лучшем случае i686. Теоретически при указании gcc компиляции кода под заданный проц. код должен получаться быстрее. Но никто тестами пока это не подтвердил, потому что непонятно что тестировать и как. Судя по всему прирост будет не во всех задачах. Я сижу на таком откомпиленном ядре, в принципе тачила мощная так что ей пофик на каком ядре работать.
Но спросите любого гентушника - он вам ответит что gentoo работает процентов на 15 быстрее. Скорее всего эти проценты взяты с потолка, и гентушники в них свято верят, иначе если не верить в это, зачем же тогда компилять всю систему?
Думаю перекомпиляция ядра в производительности заметно не добавит. Вот пересборка glibc, GTK, QT думаю даст процентов 10-15. Не факт что при этом не добавится трудновоспроизводимых глюков.
перекомпильни, да замеряй утилитой bootchart. посмотри графики, подумай.
> Не факт что при этом не добавится трудновоспроизводимых глюков.Регулярно вижу криворуких уродов (с понятно какой системой), которые сперва как ввинтят флагов для "адской оптимизации" на целых два этажа, со всей дури, чтобы выжать еше 3% скорости vs -O2, а потом идут и со всей дури плакаются в багтрекеры: "в вашей программе баг!". Хотя на самом деле баг в 80% случаев сугубо в мозгах дятла который ввинтил свой трехэтажный малопротестированный набор фич оптимизации и резонно поимел неочевидные глюки. Связанные с тем что такую дикую этажерку флагов оптимизации никто до него вообще не тестировал и компилер оказывается изредка в такой ситуации генерит слегка глючный код, перемудрив с оптимизацией. Не, ну ладно б еще авторам гцц баги писали, если уж так принципиально чтобы эта этажерка все-таки полетела и не глючила именно с таким набором флагов, так ведь нет, за что-то мозг выносят ни в чем не виноватым авторам постороннего софта. Которые ни разу не виноваты в том что у очередного пионера жопа просила приключений, елки.
10-15% ???я вас жутко разочарую - в общем случае это будет 0-3%.
> Думаю перекомпиляция ядра в производительности заметно не добавит. Вот пересборка glibc,
> GTK, QT думаю даст процентов 10-15. Не факт что при этом
> не добавится трудновоспроизводимых глюков.Гентушники тихо хохочут в сторонке. Грамотная пересборка всей системы даёт от 10% до 250% (двести пятьдесят, это не опечатка), в зависимости от приложения. Из багов, вызванных сборкой из исходников, за три года не нескольких разных системах поймал только один.
Проводили, и не раз. Естественно, толку никакого.Задрачивание флагов компиляции, сборка монолита "без лишних модулей" и без initrd - на обычном десктопе это гентушно-юношеский максимализм. С возрастом проходит.
> Проводили, и не раз. Естественно, толку никакого.
> Задрачивание флагов компиляции, сборка монолита "без лишних модулей" и без initrd -
> на обычном десктопе это гентушно-юношеский максимализм. С возрастом проходит.Я вполне себе юн и свеж, а под гентой уже более 5 лет, и так и думал, как и вы, про флаги компиляции. Но вот попался один бд-рип ("baraka", не суть важно), и встроенная видяйка на базе geforce 8200 - не тянула, vdpau ругалось. Воткнул видимокарту на базе gt210 - помогло, но не полностью. Добавил в юсе флаги sse, sse2, реемергнул ффмпег, мплеер, влц - без изменений. Емергнул ворлд с этими новыми флагами (newuse) (потратилось сутки на мои 520 пакетов), о Чудо! Всё акей, никаких подёргиваний, красиво. Отрицательный момент - не могу сказать какой именно пакет сыграл свою роль.
>[оверквотинг удален]
>> на обычном десктопе это гентушно-юношеский максимализм. С возрастом проходит.
> Я вполне себе юн и свеж, а под гентой уже более 5
> лет, и так и думал, как и вы, про флаги компиляции.
> Но вот попался один бд-рип ("baraka", не суть важно), и встроенная
> видяйка на базе geforce 8200 - не тянула, vdpau ругалось. Воткнул
> видимокарту на базе gt210 - помогло, но не полностью. Добавил в
> юсе флаги sse, sse2, реемергнул ффмпег, мплеер, влц - без изменений.
> Емергнул ворлд с этими новыми флагами (newuse) (потратилось сутки на мои
> 520 пакетов), о Чудо! Всё акей, никаких подёргиваний, красиво. Отрицательный момент
> - не могу сказать какой именно пакет сыграл свою роль.а ведь мог почеловечески перекодировать фильм в mpeg2
Но нам простых дел не поручают.
> а ведь мог почеловечески перекодировать фильм в mpeg2Что, серебряных пуль и осиновых кольев на всех не хватило?! Некроманы за человеков не считаются!
Кстати да. Правда на 720p, но и на более слабом проце... vdpau, как оказалось, не завелось... А я и не заметил. Хотя это более идеологический вопрос, пожалуй. Меня вот коробит, что у меня тут sse2, sse3, ну и вообще весь такой из себя проц..., а собрано всё под generic amd64.... ( Это если ось 64 битная... А так и под i386 вообще.
> А какие-нибудь performance тесты не проводили? Есть ли какой-нибудь реальный смысл во всем этом?Когда я н лет назад развлекался пересборкой ядра, то не стряпал в дцатый раз посты, как собрать ядро под линукс, а как раз тесты и проводил. Вроде разница была заметна на глаз. +/- 20-30 секунд при 3х минутной распаковке архива. Хотя было давно и уже толком не помню.
Наверное, топики про пересборку ядра, взломом вайфай ... (что там еще?) никогда не умрут.%(
кто то тестит, кто то пишет статьи, у каждого свой путь
Так лабораторка - компиляция ядра, вариант №4 - Core Duo, а вот Саньку не повезло, вариант №7 - armv5tejl. Он теперь себе ищет коробочку с таким :(
если при компиляции ядра посмотреть на те опции которые используютя при компиляции(ps af | grep cc1), то там почему-то нету тех опций которые заданы через export CFLAGS="..."
> если при компиляции ядра посмотреть на те опции которые используютя при компиляции(ps
> af | grep cc1), то там почему-то нету тех опций которые
> заданы через export CFLAGS="..."хоть до одного дошло, что кто-то жОстко троллит!
Вот сейчас проверял у меня ps af | grep cc1 выдаёт следующее:\_ /usr/lib/gcc/i686-linux-gnu/4.4.5/cc1 -quiet -nostdinc -I/usr/src/linux-source-2.6.35/arch/x86/include -Iinclude -Iubuntu/include -D__KERNEL__ -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(apic_noop) -DKBUILD_MODNAME=KBUILD_STR(apic_noop) -isystem /usr/lib/gcc/i686-linux-gnu/4.4.5/include -include include/generated/autoconf.h -MD arch/x86/kernel/apic/.apic_noop.o.d arch/x86/kernel/apic/apic_noop.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase apic_noop.c -m32 -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=core2 -mtune=generic -maccumulate-outgoing-args -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -auxbase-strip arch/x86/kernel/apic/.tmp_apic_noop.o -g -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -Wno-format-security -Wno-sign-compare -Wframe-larger-than=1024 -Wdeclaration-after-statement -Wno-pointer-sign -p -fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks -freg-struct-return -ffreestanding -fstack-protector -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-strict-overflow -fconserve-stack -fstack-protector -o -
то есть как вы можете наблюдать опции -march=i686 -mtune=core2 проставлены. У меня процессор core 2 duo, и эти опции компилятор автоматически поставил вместо -march=native
видимо лучше жёстко проставить -march=core2 для более лучшей оптимизации, ибо как извесно опции -march=i686 -mtune=core2 выдают код который будет работать на процессорах от pentiumpro(i686) и выше, при жёстком указании -march=core2 будет выдавать код чисто для core2
> и эти опции компилятор автоматически поставил вместо -march=nativeСам придумал?
native
This selects the CPU to tune for at compilation time
by determining the processor type of the compiling
machine. Using -mtune=native will produce code
optimized for the local machine under the constraints
of the selected instruction set. Using -march=native
will enable all instruction subsets supported by the
local machine (hence the result might not run on
different machines).-fno-omit-frame-pointer, тоже само поменялось?
Не понял чо не так?
Поправьте если лучше знаете.
Насчёт -fno-omit-frame-pointer не в курсе, не специалист
> Не понял чо не так?
> Поправьте если лучше знаете.
> Насчёт -fno-omit-frame-pointer не в курсе, не специалистДолго рассказывать. Хотите поменять флаги компиляции ядра?!
Тогда меняйте их:Глобальные, в основном Makefile (где-то в районе 230 строки)
HOSTCFLAGS=
HOSTCXXFLAGS=Тут низя писать флаги оптимизации под конкретный процессор !!!
можно типа -06/-O99, -frecord-gcc-switches, -g0 -funroll-all-loops
-ftree-vectorize -fno-inline-functions-called-once
-fmerge-all-constants, ну и так далее...
---Для оптимизации под конкретный процессор надо менять в arch/x86/Makefile (под 32 бита в arch/x86/Makefile_32.cpu)
там найти свой проц, после строки export BITS есть тройка ifeq-else-endifДописывать можно к последнему KBUILD_CFLAGS
Тут можно всё, кроме FPU/SSE/MMX/3DNOW, -mcmodel=kernel не менять!!!
> Глобальные, в основном Makefile (где-то в районе 230 строки)
> HOSTCFLAGS=
> HOSTCXXFLAGS=
> Тут низя писать флаги оптимизации под конкретный процессор !!!
> можно типа -06/-O99, -frecord-gcc-switches, -g0 -funroll-all-loops
> -ftree-vectorize -fno-inline-functions-called-once
> Для оптимизации под конкретный процессор надо менять в arch/x86/Makefile (под 32 бита
> Тут можно всё, кроме FPU/SSE/MMX/3DNOW, -mcmodel=kernel не менять!!!вот жесть то! можот ну его нафик?
> вот жесть то! можот ну его нафик?Конечно нафиг, там и так всё нормально, тем более, что
-pipe и -fomit-frame-pointer и так по умолчанию есть.
-mtune=core2 у вас проставлены потому что вы при конфигурировании ядра задали "Processor family" core2
> -mtune=core2 у вас проставлены потому что вы при конфигурировании ядра задали "Processor
> family" core2вы уверены?
у меня -march выставляет только в зависимости от опции в конфиге "Processor family", а опции из CFLAGS не применяются. проверял с export CFLAGS="-march=native -O3", в итоге выходило -march=(то что я выбрал в конфиге, пробовал несколько вариантов k8 и x86-64, а native должен дать amdfam10) и -O2
> у меня -march выставляет только в зависимости от опции в конфиге "Processor
> family", а опции из CFLAGS не применяются. проверял с export CFLAGS="-march=native
> -O3", в итоге выходило -march=(то что я выбрал в конфиге, пробовал
> несколько вариантов k8 и x86-64, а native должен дать amdfam10) и
> -O2Да не использует ядро переменную CFLAGS из окружения.
Проверить легко - надо задать неправильные флаги:export CFLAGS="-mtune=shit -march=govno"
---
Хотите заменить, тогда задаёте
# export HOSTCFLAGS="-O99 -mtune=native -funroll-all-loops"
# export KBUILD_CFLAGS="-O99 -mtune=native -funroll-all-loops"
# make -e menuconfig
# make -eЦеликом менять не надо, скопируйте старые HOSTCFLAGS и KBUILD_CFLAGS
и добавьте или замените нужное. Так как make -e перепишет полностью
эту переменную из Makefile вашими.Если всё поломаете, сами виноваты. :)
В общем вывод делаем такой:
1. переменные окружения на параметры компиляции не влияют
2. Оптимизация под процессор выставляется в опциях ядра make menuconfig "Processor family"
> В общем вывод делаем такой:
> 1. переменные окружения на параметры компиляции не влияют
> 2. Оптимизация под процессор выставляется в опциях ядра make menuconfig "Processor family"для 32-х битов есть ещё REGPARM
на Core2Duo/Athlon64 и выше можно врубить CONFIG_JUMP_LABEL
на gcc 4.х и выше CONFIG_OPTIMIZE_INLINING
на AMD64: SMT (Hyperthreading) scheduler вырубить, врубить только Multi-core scheduler
Вам ещё страниц 500, про оптимизацию ядра? :)
Что то не нашёл я у себя в ядре опций REGPARM и CONFIG_JUMP_LABEL
CONFIG_OPTIMIZE_INLINING есть
может у меня ядро не то? 2.6.35
Не 500 страниц я ниасилю, тем более наверняка на инглише,
к оптимизации ядра я уже давно перегорел, сижу на стандартном и не дёргаюс.Но эти опции в переменных окружения всё равно полезно выставлять, так как те программы которые ты будешь компилировать из исходников будут компиляться с этими параметрами
>> В общем вывод делаем такой:
>> 1. переменные окружения на параметры компиляции не влияют
>> 2. Оптимизация под процессор выставляется в опциях ядра make menuconfig "Processor family"
> для 32-х битов есть ещё REGPARM
> на Core2Duo/Athlon64 и выше можно врубить CONFIG_JUMP_LABEL
> на gcc 4.х и выше CONFIG_OPTIMIZE_INLINING
> на AMD64: SMT (Hyperthreading) scheduler вырубить, врубить только Multi-core scheduler
> Вам ещё страниц 500, про оптимизацию ядра? :)мне бы скриптик который проанализировав моё железо выставил нужные настройки под мою машину.. но это же линукс, тут так походу не принято, автоматизация для слабых виндузятников
> мне бы скриптик который проанализировав моё железо выставил нужные настройки под мою
> машину.. но это же линукс, тут так походу не принято, автоматизация
> для слабых виндузятниковвесь виндавозный мир сидит на дефолтовом ядре и не гундит
>[оверквотинг удален]
>>> 1. переменные окружения на параметры компиляции не влияют
>>> 2. Оптимизация под процессор выставляется в опциях ядра make menuconfig "Processor family"
>> для 32-х битов есть ещё REGPARM
>> на Core2Duo/Athlon64 и выше можно врубить CONFIG_JUMP_LABEL
>> на gcc 4.х и выше CONFIG_OPTIMIZE_INLINING
>> на AMD64: SMT (Hyperthreading) scheduler вырубить, врубить только Multi-core scheduler
>> Вам ещё страниц 500, про оптимизацию ядра? :)
> мне бы скриптик который проанализировав моё железо выставил нужные настройки под мою
> машину.. но это же линукс, тут так походу не принято, автоматизация
> для слабых виндузятниковНу в Венде тоже есть ключи реестра, которые, кроме особо посвящённых,
не знают как использовать.
Кстати, gcc 4.5 (может и в более ранних версиях) выдаёт чуть больше оптимизаций, чем просто подстраивание march под ваш проц. Там что-то типа cach-line-size и что-то ещё в этом роде. Сейчас под рукой нет. Конфетка, вобщем. Кстати, собирать _только_ едро с march=native и проч. не вижу особо смысла без пересборки, хотя бы, мира. Там то уж оптимизации побольше подразгуляются, ИМХО.
Компиляция ядра дает выигрыш в том случае, когда вы выбираете нужные драйверы, службы и т.д., а удаляете не нужные. В этом случае ядро становится компактным без лишнего, не нужного ВАМ кода. В остальных случаях ядро компилят с включением каких-то специализированных патчей, например, для протокола SPICE. И в том и в другом случае напортачить можно на раз, поэтому если нужна производительность - отказывайтесь от универсальных дистрибутивов в пользу заточенных под определенную задачу
Я в это не верю.
Сейчас в дистрибутивах ядро весит не более 10 Мб, при этом обычно разработчики дистрибутивов включают в ядро самое необходимое, а доп опции компилируют модулями, которые подключаются автоматически, если обнаруживается соответствующее оборудование или ПО либо при указании вручную в соотвествующих конфигах.
Я потрачу несколько дней чтобы убрать всё ненужное из ядра, и что бы оно при этом компилялось, что бы оно полегчало пусть на 1 МБ? Оно мне надо? У меня памяти несколько Гигов, своп вообще не юзается, я таких ядер десятками в памяти держать могу.
Вопросы веры тут не обсуждаются, здесь в основном люди факты любят.
Монолит собранный из нужных частей всегда будет работать быстрее. Доказывать ничего не собираюсь, велком ту мир ASM.
Возьмите в качестве примера звуковую карту на сервере (файловом, почтовом, СУБД и т.д.): на фига будет выполнятся эти инструкции (по прерыванию) на этом сервере. Остальное, я думаю, додумаете сами
Ну да, разве что в этом случае, позволит сэкономить несколько тактов процессорного времени
под убунтой на ноутах можен не скомпилится. нашел багрепорт
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/505420
там костыль есть для быстрого решения проблеммы
ln -s /usr/src/linux-2.6.35/ubuntu /ubuntu
А с какими опциями лучше собирать ядро под процессор core i5 2300(Sandy Bridge) ?
> А с какими опциями лучше собирать ядро под процессор core i5 2300(Sandy
> Bridge) ?linux=remove, windows=install, очевидно же. если не знаешь, не лезь.
>> А с какими опциями лучше собирать ядро под процессор core i5 2300(Sandy
>> Bridge) ?
> linux=remove, windows=install, очевидно же. если не знаешь, не лезь.Класс ответ. А если не лезть то хер когда узнаешь.
в этой статье неверные данныечитайте хотя бы http://forums.gentoo.org/viewtopic-t-24849-start-0.html
автору - сначала хорошо поищи информацию, нечего людей дизинформировать
Вот смотрю я на опции выбора CPU в ядре (да и в GCC), и думаю, Intel Core 2 == Phenom II? А то на Athlon 64 всё так с AMD и застыло.
кажись для xp и x2 есть варианты. или у меня это патчи?
И ещё: регулярно исполбзую make-kpkg, но пока не удалось после нанесения очередного patch-2.6.xx.x пересобрать пакет без полного предшествующего make-kpkg clean. А нужно-то было бы всего несколько (пропатченных) файлов перекомпилить, вместо всего ядра. Или есть у make-kpkg где-то такая фича, чтобы гибче было?
Чет не пойму к чему это все и зачем, сделайте нормальную wiki страницу под разными CPU + описание ключей компиляции и типовые тесты, бенчмарки к ним, вот тогда было бы с чем сравнить и видеть куда оптимизировать. А так каждый изобретает свое колесо .... в своем понимании формата колеса ....