Комментарии 77
Цель эксперимента? Уменьшить футпринт по памяти? Или в чем сакральный смысл?
Это в частности приводит к тому, что перекомпиляция ядра превращается в достаточно длительный процесс.
Зачем? Если все «нормальные» люди уже давным давно ядра берут из бинарных deb/rpm?
На моей рабочей машине (i7, 8 cores, 64gb RAM, tmpfs) финальная конфигурация собирается за 1m 16s.
Неплохой результат, поздравляю
$ ll arch/x86/boot/bzImage && grep -v ^# .config|grep -c .
-rw-rw-r-- 1 kvt kvt 2020000 Feb 1 14:16 arch/x86/boot/bzImage
566
$и к освобождению памяти это тоже не приводит:
instance-20210124-1735 ~ # free -h
total used free shared buff/cache available
Mem: 996Mi 17Mi 944Mi 0B 34Mi 965Mi
Swap: 0B 0B 0B
instance-20210124-1735 ~ #
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_CPU_SUP_HYGON=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_ZHAOXIN=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_FAN=y
CONFIG_WIRELESS=y
CONFIG_THERMAL=y
CONFIG_DEBUG_KERNEL=y
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_LOCK_DEBUGGING_SUPPORT=y
$ ll arch/x86/boot/bzImage && grep -v ^# .config|grep -c .
-rw-rw-r-- 1 kvt kvt 2003616 Feb 2 14:52 arch/x86/boot/bzImage
559
$ diff .config.old .config
358,359c358,359
< CONFIG_ACPI_AC=y
< CONFIG_ACPI_BATTERY=y
---
> # CONFIG_ACPI_AC is not set
> # CONFIG_ACPI_BATTERY is not set
361c361
< CONFIG_ACPI_FAN=y
---
> # CONFIG_ACPI_FAN is not set
363d362
< CONFIG_ACPI_CPU_FREQ_PSS=y
365,368c364
< CONFIG_ACPI_PROCESSOR_IDLE=y
< CONFIG_ACPI_PROCESSOR=y
< # CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
< CONFIG_ACPI_THERMAL=y
---
> # CONFIG_ACPI_PROCESSOR is not set
$Убрать CONFIG_CPU_SUP_* не получается, make возвращает их в .config.
просто угарнуть в стиле пикабу.Извиняюсь за оффтопик, но наблюдаю стойкую тенденцию — сначало на пикабу было вообще моветон ссылаться, а тут уже даже комплимент почти:)
Цель эксперимента? Уменьшить футпринт по памяти? Или в чем сакральный смысл?
Пршу прощения, я в самом начале поста указал, что машина маломощная, хотелось ускорить перекомпиляцию. Это gentoo, так что конкретно в этом случае компиляция из исходников является штатным способом обновления.
ОКей, а какова цель замены убунту на генту? Просто "угарнуть в стиле пикабу."?
что машина маломощная, хотелось ускорить перекомпиляцию
ну, пацаны же знают про кросс-компиляцию на других машинах ))) И Вы же сами про это пишете…
Зачем? Если все «нормальные» люди уже давным давно ядра берут из бинарных deb/rpm?
ну вопервых генту и deb/rpm живут в разных мирах
а во вторых в генту есть "пакет" с бинарным ядром который можно просто поставить а не компилять
а вот почему автор топика не оставил ссылку на имя и пример конфига сервера сборки загадка, если он вручную занимался перекидываниями то ему ещё есть чему поучится
Я уже пару лет как с генты ушёл
Но выглядело это так: emerge запускаю на своей тачке, а сборка работает на vps где-то далеко доставшемся мне бесплатно, там вроде тоже Убунта была, непомню
ну вопервых генту и deb/rpm живут в разных мирах
да эт понятно ) Мы тоже очень долго использовали генту, но потом в какой-то момент решили, что весь гемор с ней не стоит потраченных усилий. И катнулись на убунту. /это был один известный российский веб-хостинг/
А как изменился
free -h
в "минимальной" системе и "из коробки"? Что изменилось по существу, насколько изменилось? Может, что-то ещё, кроме занятой памяти изменилось?
instance-20210124-1735 ~ # free -h
total used free shared buff/cache available
Mem: 996Mi 17Mi 944Mi 0B 34Mi 965Mi
Swap: 0B 0B 0B
instance-20210124-1735 ~ #
Система после конвертирования из ubuntu 20.04, 1285 параметров в .config:
instance-20210111-0918 ~ # free -h
total used free shared buff/cache available
Mem: 986Mi 22Mi 921Mi 0.0Ki 43Mi 872Mi
Swap: 0B 0B 0B
instance-20210111-0918 ~ #Эм, я что-то в этой жизни не понимаю, но общей видимой памяти во втором варианте стало меньше на 10MB. А Used даже стал больше. Итого — available меньше на ~70MB (WAT?)
Скорее всего total стал меньше, тк bios(UEFI) зарезервировал часть памяти для устройств.
Она, разумеется, уменьшает размер «available», но если ты попросишь больше, чем есть available, то все буферы и кэши выгрузятся почти до нуля. Смотреть нужно на «used» + «shared».
да я уже понял, что не туда посмотрел, спасиб, потому что автор не четко написал где какое ядро )
В общем — по ходу "оптимизированное" ядро видит на 10МБ памяти больше (колонка total). При этом "used" меньше на 5 МБ. Разница по available, внезапно, может быть из-за разных опций кэширования в разных ядрах и конфигах
Я не стал заниматься перфекционизмом и вычищать абсолютно все, что не нужно.
Исходя из заголовка я ждал именно этого, а 2мб… вау эффекта нет. Если бы мне гентушник сказал «А у меня ядро всего 2мб и полностью рабочее» я бы ему даже поверил, потомучто в убунте ядро 4.15 8мб занимает, всего в 4 раза больше.
Размер ядра самого может и реально буквально там 4-5 мегабайт, но вот пакет с ядром 250 мегабайт, в него видимо входят всякие initrd и подобное на все случаи жизни. Я ставил опыты на виртуалках Hyper-V, хотелось минимальный образ виртуалки собрать для своих целей и 250 мегабайт ощутимый размер, после пересборки с командами типа
make localmodconfig && make localyesconfig
Получился пакет ядра буквально там мегабайт на 10.
Аналогичный профит получал еще в году 2009, когда на атомном нетбуке патчил ядро (контроллер sata фризил), если просто пропатчить и собрать с параметрами стандартными от дистрибутива, то компилировалось на ноуте часов 10 (да, компа не было, только нетбук), но когда минимизировал конфиг сборки, то буквально за полчаса собралось.
А автору статьи хочу сказать чтобы сравнивал размеры не ядра, а модулей, которые не вкомпилированы в ядро, но тоже собираются.
… потомучто в убунте ядро 4.15 8мб ...
Вы уверены?.. Или initrd (initramfs) уже за kernel не считается? (ну попробуйте удалить… если никакие дрова или модули ядра на стадии бута не нужны, может и взлетит).
Не убунту, но тоже дебиан — (v.4.19) 48MB со всем барахлом (притом упакованным):
$ du -hc /boot/*-$(uname -r)
203K /boot/config-4.19.0-13-amd64
39M /boot/initrd.img-4.19.0-13-amd64
3.3M /boot/System.map-4.19.0-13-amd64
5.1M /boot/vmlinuz-4.19.0-13-amd64
48M total
$ file /boot/initrd.img-$(uname -r)
/boot/initrd.img-4.19.0-13-amd64: gzip compressed data, ..., original size 136074240kt97679, я без понятия как оно для gentoo там (если всё собирается одним куском в ядро), но… strip случайно не забыли? :)
Даже на х86, можно все драйвера скомпилировать в ядро и оно замечательно запустится на целевой машине.
Конечно можно, я не спорю… только это не так в той "убунте, с ядром 4.15 8мб", где оно всё лежит и в initrd в том числе.
Автор же собрал ядро без модулей (со статически слинковаными дровами)…
Поэтому я и написал как написал.
Вдохновил меня сделать что-то подобное с целью уменьшить attack surface в виртуальной машине. User space я уже минимизировал, а вот ядро оставил. Надо бы его тоже порезать, в частности выпилить поддержку модулей.
В статье не хватает размеров файла ядра до оптимизации и после.
Вот когда мы занимались впихиванием OpenWRT с относительно свежим ядром и OpenVPN в Linksys WRT54GL у которого всего 4МБ флеша — это был челлендж.
А то что в статье… даже не знаю зачем, особенно если автор даже поленился отключить руками тонны ненужных дров.
Кому интересны крайности — может смотреть в сторону Firecracker и оптимизированных под него ядер. ВМ там грузятся за миллисекунды...
Firecracker идеологически мне тоже очень нравится, но oracle cloud использует kvm, так что приходится ориентироваться на него.
Выше я уже ответил, что удаление, к примеру, драйверов сетевых адаптеров, не привело к уменьшению размеров ядра.
Ну вы же понимаете что так быть не может. Все драйвера, как и прочие модули, компилируются в объектные файлы и линкуются в единый бинарник, который потом сжимается каким-нибудь LZMA или что там выбрано в конфиге. И исключение пары десятков ненужных сетевух и тех же storage контроллеров (всё кроме virtio) сильно уменьшает результат.
В первую очередь мне хотелось уменьшить время компиляции.
А зачем вообще в наше время заниматься сборкой ядер? Если это конечно не embedded...
Наверное, что бы обновлять ядра было не больно. Это же генту, там с сырцов обновляется :)
Генту, как и всякие (B)LFS, хороши для тех, кто хочет изучить внутреннее устройство ОС. Или для задротов, которые хотят выжать лишние пол-процента производительности через emerge world + CFLAGS='-march=native -O3'
Для всех остальных это зло, в серьезном продакшене использовать очень тяжело и бессмысленно. Если нужна производительность — проще пересобрать нужные пакеты с правильными флагами и залить в локальную репу.
Я некоторое время назад поменял Fedora на Gentoo, потому что несколько устал бороться с дефолтными конфигами и страным поведением системы в моих кейсах, связанных в основном с виртуализацией, несколькими видео- и звуковыми картами (pulse почему-то крайней нестабильно работал и вел себя странно, причем апдейт версии в рамках релиза федоры не помогал, возможно что-то с конфигами дефолтными было не так...), использованием Enlightenment в роли WM и отсутствия необходимости в полном пакете софта из гнома или kde и т.д. Ubuntu как вариант не рассматривал, она норм конечно, но я боюсь еще одна починка поломавшегося об цикличесую зависимость apt меня просто добьет. Случается это конечно весьма не часто (пожалуй раза 3 всего было за те 14 лет, что я ей пользовался так или иначе), но сама возможность такой ситуации меня несколько нервирует. Я если что лучше ручками поправлю или соберу, чем буду бороться с dependency cycling или подобным.
Но в прод да, я бы пожалуй ее не потащил, слишком много гемороя и мало смысла. Да и в большинстве случаев там все равно все в контейнерах, эксплуатационные расходы не окупят всей суеты.
Ну, десктоп я даже не рассматривал, автор про ВМ в облаках речь ведёт...
Я, конечно, когда-то жил на десктопе с гентой, когда был сильно моложе и времени было много чтобы подождать пока файрфокс или опенофис соберутся :)
Но, по-моему, Linux как 20 лет назад не был готов к десктопу, так и сейчас не готов. Понятное дело что жить можно если заниматься только, допустим, разработкой. Но отсутствие большого количества коммерческого софта напрягает.
Но это уже оффтопик :)
времени было много чтобы подождать пока файрфокс или опенофис соберутся
Офтопик конечно, но я тут проапгрейдился до 5950x со старенького Xeon и в общем-то сборка совершенно перестала напрягать. Всякая мелочевка собирается вообще мгновенно, apt индексы дольше пересчитывал, Firefox ~ за 9 минут от запуска emerge, а вот Chromium да, хром тот еще тормоз.
На счет готовности — ну очевидно я на нем не играю (в виртуалке играю, куда видюха проброшена), но вот в плане поработать все-таки удобнее, не смотря на WSL в винде. А мак просто выйдет безумно дорого в серьезной конфигурации. За коммерческий софт — да, пожалуй, но каждый выбирает инструмент под свои потребности:)
Firecracker тоже использует KVM. Он замена qemu.
Я думаю, что скорее речь про то, что там внутри — MicroVMM и все прочее. Именно само ядро виртуалки с минимальным footprint — и это справедливо, т.к. в виртуальных средах оборудование стандартизовано
Ну там впринципе обычное ядро линукса урезанное, поэтому опции можно подглядеть. Только чую я, судя по коду, что там используется virtio + mmio, а не PCI. Поэтому да, в Oracle Cloud такое ядро не запустишь.
В 1999 у меня была дискета загрузочная Debian с сетью, GUI и браузером. И это имело практический смысл.
А когда речь не идёт о дискете — незачем и экономить.
Вообще жор ресурсов современных ОС просто поражает. Помню в 2012 году мне для моего веб-проекта вполне хватало впс-ки с 128 мегабайтами памяти. Там была freebsd (вроде 8), php 5.3, nginx, mysql и ejabberd. Потом для отбивания ддоса пришлось расширить память до 192 мегабайт. И этого блин хватало чтобы даже ддос отбивать! А что сейчас? Сейчас впс-ка с гигом памяти кое как шевелится и помирает от малейшей нагрузки.
Как-то, учась в институте, собирал ядро 2.6, rootfs и вот это все под отладочную плату с процом AT9260, где было 4 Мб флэша. Помню, я даже не смог туда засунуть libc++, только libc. Возможно, можно было ужать сильнее, но это было мое практически первое знакомство с линуксом.
Размер ядра вместе со вшитым в initramfs юзерспейсом — 1054576 байт.
Конфиг: pastebin.pl/view/ed53ec7b
В получении образа такого размера не было какой-либо особой сложности.
Насколько маленьким может быть ядро linux?