[devel] Модульный initrd.img

[devel] Модульный initrd.img

[Michael A. Kangin]

Здравствуйте!

Не секрет, хотя и не широкоизвестно, что популярные загрузчики позволяют 
указывать несколько cpio-образов, которые при загрузке будут объединены 
в памяти в единую initramfs.

Этим можно воспользоваться, и разделить текущий монолитный initrd.img на 
отдельные образы - собственно сам initrd, early-микрокод, и модули ядра 
[с фирмварью].

Зачем это может быть нужно?
- ускорение генерации новых initrd при установке нового ядра. Если 
микрокод и само тело initrd остаётся такими же, достаточно только 
быстренько слепить образ с новыми модулями.
- уменьшение суммарного размера микрокода / разных вариантов initrd / 
разных версий ядра. Например, мы выносим микрокод отдельным образом - и 
нам не нужно включать его в каждую новую версию initrd, которую мы 
делаем. Если мы генерим себе -debug initrd, то достаточно сделать 
крохотный diff-образ с bash / lsmod / whatever, а модули и основной 
initrd у нас уже есть. Мы можем предложить загрузить на выбор std-def и 
un-def, причём разница (кроме самих vmlinuz'ов) будет достаточно 
небольшая, архивы из десятка модулей ядра.
- возможность оперативно фиксить уже существующий initrd, добавив сбоку 
в отдельном образе или недостающий модуль, или конфиг там какой со скриптом.
- возможность полностью отвязать сам initrd от версии ядра. И иметь 
возможность загрузить систему с, например, RHEL-овским ядром, но нашим 
initrd, не ломая никакой совместимости.

Минимальная поддержка, необходимая в initrd для сторонних образов с 
модулями - вызов "depmod -a" перед загрузкой модулей, например, в стадии 
pre-udev. Если сторонние образы содержат что-то другое, то и поддержки 
особой не надо.

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

Вот пара вполне работающих примеров:

syslinux с семейством (iso, pxe):
=======================
LABEL test-modular-initrd
MENU LABEL Test modular initrd
KERNEL clb/vmlinuz
INITRD clb/microcode.img,clb/initrd-thin.img,clb/supermicro_boot.modules
APPEND root=http://xxxxx/rescue-base-sm.manifest rootdelay=5
=======================
Работает как с legacy bios, так и с uefi.

grub2:
=======================
...
echo    'Loading Linux 4.9.71-std-def-alt0.M80P.1 ...'
linux   /boot/vmlinuz-4.9.71-std-def-alt0.M80P.1 
root=UUID=a397ac93-3b06-4023-83e4-18b29a28b033 ro  quiet 
resume=/dev/disk/by-uuid/6481d48d-8403-4049-adfc-87e94b950361 panic=30 
splash
echo    'Loading initial ramdisk ...'
initrd  /boot/microcode.img 
/boot/initrd-4.9.71-std-def-alt0.M80P.1-thin.img /boot/modules.img
=======================
c uefi не пробовал.

Так же, не знаю, умеют ли это хитрые uefi-загрузчики типа refind'а.

Re: [devel] Модульный initrd.img

[Leonid Krivoshein]

Добрый вечер!


06.05.2018 19:55, Michael A. Kangin пишет:
> Здравствуйте!
>
> Не секрет, хотя и не широкоизвестно, что популярные загрузчики 
> позволяют указывать несколько cpio-образов, которые при загрузке будут 
> объединены в памяти в единую initramfs.
>

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


> Этим можно воспользоваться, и разделить текущий монолитный initrd.img 
> на отдельные образы - собственно сам initrd, early-микрокод, и модули 
> ядра [с фирмварью].
>

Если не ошибаюсь, ucode для initel/amd у нас тоже сейчас отделён. Цена 
вопроса в любом из вариантов -- выравнивание кусков по 4Кб границам, 
если не ошибаюсь, они склеиваются не встык, а должны выравниваться по 
границам размера страницы.


> Зачем это может быть нужно?
> - ускорение генерации новых initrd при установке нового ядра. Если 
> микрокод и само тело initrd остаётся такими же, достаточно только 
> быстренько слепить образ с новыми модулями.

Это значит капитально переделывать инструмент генерации initrd, другие 
дистрибутивные инструменты, которые это должны поддерживать. Ради чего? 
Так ли уж долго генерируется initrd? И ведь нужно ещё вести учёт того, 
что менялось, а что нет.


> - уменьшение суммарного размера микрокода / разных вариантов initrd / 
> разных версий ядра. Например, мы выносим микрокод отдельным образом - 
> и нам не нужно включать его в каждую новую версию initrd, которую мы 
> делаем. Если мы генерим себе -debug initrd, то достаточно сделать 
> крохотный diff-образ с bash / lsmod / whatever, а модули и основной 
> initrd у нас уже есть. Мы можем предложить загрузить на выбор std-def 
> и un-def, причём разница (кроме самих vmlinuz'ов) будет достаточно 
> небольшая, архивы из десятка модулей ядра.

Для решения конкретных задач всё равно будут пары ядро+initrd, а любые 
попытки приведут к небольшому увеличению конечного образа, но не наоборот.


> - возможность оперативно фиксить уже существующий initrd, добавив 
> сбоку в отдельном образе или недостающий модуль, или конфиг там какой 
> со скриптом.

Чтобы его оперативно пофиксить сейчас достаточно сказать make-initrd.


> - возможность полностью отвязать сам initrd от версии ядра. И иметь 
> возможность загрузить систему с, например, RHEL-овским ядром, но нашим 
> initrd, не ломая никакой совместимости.
>

make-initrd умеет класть в образ initramfs любые файлы и сейчас.


> Минимальная поддержка, необходимая в initrd для сторонних образов с 
> модулями - вызов "depmod -a" перед загрузкой модулей, например, в 
> стадии pre-udev. Если сторонние образы содержат что-то другое, то и 
> поддержки особой не надо.
>

Сейчас автоугадав взаимных зависимостей модулей работает на этапе 
генерации initrd. Чего же хорошего в переносе этой длительной операции 
на этап КАЖДОЙ (!) загрузки машины?


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

Так и сейчас чтобы сгенерировать initrd с определёнными фичами или 
наоборот, без них, достаточно подправить /etc/initrd.mk и сказать 
make-initrd. Именно так можно избавиться от плимута, к примеру.


> Вот пара вполне работающих примеров:
>
> syslinux с семейством (iso, pxe):
> =======================
> LABEL test-modular-initrd
> MENU LABEL Test modular initrd
> KERNEL clb/vmlinuz
> INITRD clb/microcode.img,clb/initrd-thin.img,clb/supermicro_boot.modules
> APPEND root=http://xxxxx/rescue-base-sm.manifest rootdelay=5
> =======================
> Работает как с legacy bios, так и с uefi.
>
> grub2:
> =======================
> ...
> echo    'Loading Linux 4.9.71-std-def-alt0.M80P.1 ...'
> linux   /boot/vmlinuz-4.9.71-std-def-alt0.M80P.1 
> root=UUID=a397ac93-3b06-4023-83e4-18b29a28b033 ro  quiet 
> resume=/dev/disk/by-uuid/6481d48d-8403-4049-adfc-87e94b950361 panic=30 
> splash
> echo    'Loading initial ramdisk ...'
> initrd  /boot/microcode.img 
> /boot/initrd-4.9.71-std-def-alt0.M80P.1-thin.img /boot/modules.img
> =======================
> c uefi не пробовал.
>
> Так же, не знаю, умеют ли это хитрые uefi-загрузчики типа refind'а.

Даже если не умеет загрузчик, куски можно склеить заранее. И получить 
всё тот же монолитный initrd. Но зачем? Ведь в конечном итоге для 
решения конкретной задачи эти куски попадают на обработку всё равно уже 
в склееном виде.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Модульный initrd.img

[Michael A. Kangin]

On 05/06/2018 08:25 PM, Leonid Krivoshein wrote:

>> Минимальная поддержка, необходимая в initrd для сторонних образов с
>> модулями - вызов "depmod -a" перед загрузкой модулей, например, в
>> стадии pre-udev. Если сторонние образы содержат что-то другое, то и
>> поддержки особой не надо.
> Сейчас автоугадав взаимных зависимостей модулей работает на этапе
> генерации initrd. Чего же хорошего в переносе этой длительной операции
> на этап КАЖДОЙ (!) загрузки машины?

Мне кажется, вы не вполне понимаете, о чём речь.
Не стоит называть вызов depmod -a "автоугадавом".
На паре десятков модулей в tmpfs он стремителен.

[root@host-161 o1]# time depmod -a -b .
0.00user 0.00system 0:00.01elapsed 90%CPU (0avgtext+0avgdata 
5660maxresident)k
0inputs+424outputs (0major+1324minor)pagefaults 0swaps


> Даже если не умеет загрузчик, куски можно склеить заранее. И получить
> всё тот же монолитный initrd. Но зачем? Ведь в конечном итоге для
> решения конкретной задачи эти куски попадают на обработку всё равно уже
> в склееном виде.

Потому что выбор конкретной задачи может быть сформулирован и предложен 
в меню загрузчика. А создавать по монолитному образу на каждый из 64 
(например) вариантов в многоуровневом меню - лишние затраты ресурсов на 
генерацию и хранение (дедупликацию) одного и того же многократно.

А в случае медленной сетевой загрузки (uefi c tftp, например) 
оказывается очень важным предоставить как можно меньший образ.

Re: [devel] Модульный initrd.img

[Leonid Krivoshein]

06.05.2018 22:34, Michael A. Kangin пишет:
> On 05/06/2018 08:25 PM, Leonid Krivoshein wrote:
>
>>> Минимальная поддержка, необходимая в initrd для сторонних образов с
>>> модулями - вызов "depmod -a" перед загрузкой модулей, например, в
>>> стадии pre-udev. Если сторонние образы содержат что-то другое, то и
>>> поддержки особой не надо.
>> Сейчас автоугадав взаимных зависимостей модулей работает на этапе
>> генерации initrd. Чего же хорошего в переносе этой длительной операции
>> на этап КАЖДОЙ (!) загрузки машины?
>
> Мне кажется, вы не вполне понимаете, о чём речь.
> Не стоит называть вызов depmod -a "автоугадавом".
> На паре десятков модулей в tmpfs он стремителен.
>

Ключевое здесь -- "на паре десятков". И эту пару десятков вы хотите 
разделить на несколько отдельных initrd? :) В актуальном ядре модулей -- 
более 4400. Около 600Мб займёт генерируемый modules.dep, ещё более 700Мб 
modules.dep.bin. Понятно, что на паре десятков модулей, да ещё и на 
быстром процессоре, это может оказаться быстрее. Хотя 90% загрузка 
процессора и в/в даже в этом случае не ускоряет процесс запуска машины, 
а замедляет его. Под автоугадавом взаимных зависимостей модулей имелось 
ввиду брать не дистрибутивное, а строить зависимости заново -- этот 
процесс вынуждено выполняется на этапе make-initrd, потому что в образ 
попадают не все модули. Ваш модульный подход вынуждает переносить 
перестроение зависимостей на этап загрузки, если модули разложены по 
разным кускам.


> [root@host-161 o1]# time depmod -a -b .
> 0.00user 0.00system 0:00.01elapsed 90%CPU (0avgtext+0avgdata 
> 5660maxresident)k
> 0inputs+424outputs (0major+1324minor)pagefaults 0swaps
>
>
>> Даже если не умеет загрузчик, куски можно склеить заранее. И получить
>> всё тот же монолитный initrd. Но зачем? Ведь в конечном итоге для
>> решения конкретной задачи эти куски попадают на обработку всё равно уже
>> в склееном виде.
>
> Потому что выбор конкретной задачи может быть сформулирован и 
> предложен в меню загрузчика. А создавать по монолитному образу на 
> каждый из 64 (например) вариантов в многоуровневом меню - лишние 
> затраты ресурсов на генерацию и хранение (дедупликацию) одного и того 
> же многократно.
>

Так для реальной жизни в меню только те варианты, которые нужны. Ну и 
что, что есть пересечения по части сжатых initrd. Их куча устаревших всё 
равно на дисках валяется без надобности. Вы знаете много людей, которые 
пользуются remove-old-kernel? :)


> А в случае медленной сетевой загрузки (uefi c tftp, например) 
> оказывается очень важным предоставить как можно меньший образ.
>

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


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Модульный initrd.img

[Michael A. Kangin]

On 05/07/2018 10:42 AM, Leonid Krivoshein wrote:

> Вероятно Автоугадав здесь действительно не лучший термин, назовите его 
> Перестроителем или Построителем. :) На самом деле механизм 
> автоматического определения нужных модулей (страшный Автоугадав) большей 
> частью находится в самом ядре. И ему этот список зависимостей модулей в 
> определённый момент может потребоваться. 

Леонид, вы опять описываете это всё в очень странных терминах и 
понятиях. Я вам советую почитать маны на depmod, modules.dep, modprobe, 
для исключения путаницы, чтобы понимать, что для чего нужно.

И там нет НИКАКОГО "угадава", только списки экспортируемых и требуемых 
символов, как зависимости в RPM. Вы же деятельность apt-get update не 
называете автоугадавом?



> Чтобы перестроить (создать 
> заново) список зависимостей, нужно как минимум линейно пройтись по всем 
> заголовкам модулей, как минимум рекурсивно по всей директории с модулями 
> ядра. Для экономии времени на этапе начальной загрузки каждый модуль 
> ядра у нас пожат отдельно gzip'ом, сам же слой с модулями не пожат. На 
> этапе начальной загрузки ещё неизвестно, какие из модулей реально 
> потребуются, какие нет. Полный набор модулей (без фирмвари) -- это 
> порядка 75Мб в сжатом виде. 

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

Кроме того, я имел некоторый практический опыт по исследовательской 
загрузке многих типов хостов - виртуалки, сервера, тощие клиенты 
(включая допотопно-тормознутый Intel Atom) полным образом со всеми 
четыретыщ модулей. Задержка при загрузке от depmod не ощущается вообще 
никак, от слова "совсем", даже на вышуепомянутом атоме.
Гораздо и неизмеримо большее время уходит на прокачать такой 
бесмысленно-огромный образ по сети.

> На конкретной системе из этих 75Мб или 
> порядка 4450 модулей потребуется лишь 30-100 модулей.

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

> При загрузке 
> модулей, их распаковка выполняется автоматически. А теперь запустим 
> depmod -a на максимально возможном наборе. Чтобы заглянуть в файл 
> модуля, придётся его сначала распаковать, если не целиком, то хотя бы 
> первый блок. И так по каждому из 4450 модулей, которые ещё неизвестно, 
> потребуются или нет. gzip не умеет делать это во много потоков, только в 
> один,

Используйте pigz



>>> Так ничто не мешает сгенерировать компактный монолитный образ сейчас, 
>>> не прибегая к модульности.
>> Совершенно логически верное высказывание. Как и обратное - ничто не 
>> мешает разбить функциональность по модулям сейчас, не прибегая к 
>> монолитности.
> 
> Пока что мешает отсутствие поддержки со стороны соответствующего 
> инструментария. И кто его будет переделывать ради сомнительной (пока 
> что) выгоды?

Нет, отсутствие поддержки абсолютно не мешает использовать при желании 
эту технологию уже сейчас, в режиме "заката солнца вручную". 
Разумеется, поддержка в make-initrd по формированию отдельных образов 
была бы конечно приятным бонусом по автоматизации, но она не обязательна.

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



>> Я тут подумал - даже поддержка depmod со стороны initrd не нужна. Эту 
>> depmod и дёргающий её скриптик тоже можно притащить сторонним модулем.
>> Надо будет еще подумать, мне понравилось. Захват initrd на абордаж!

-- 
Michael A. Kangin

Re: [devel] Модульный initrd.img

[Leonid Krivoshein]

07.05.2018 14:52, Michael A. Kangin пишет:
>> Чтобы перестроить (создать заново) список зависимостей, нужно как 
>> минимум линейно пройтись по всем заголовкам модулей, как минимум 
>> рекурсивно по всей директории с модулями ядра. Для экономии времени 
>> на этапе начальной загрузки каждый модуль ядра у нас пожат отдельно 
>> gzip'ом, сам же слой с модулями не пожат. На этапе начальной загрузки 
>> ещё неизвестно, какие из модулей реально потребуются, какие нет. 
>> Полный набор модулей (без фирмвари) -- это порядка 75Мб в сжатом виде. 
>
> Полный набор модулей, включая все звуковые карточки и графические 
> планшетики, никто никогда не будет класть в initrd, они там не нужны.

Однако выше вы же привели пример дистрибутива с ядром, где в initrd 
кладутся _ВСЕ_ модули. Это во-первых. Мы же не говорим только об одной 
задаче: собрать некий оптимальный initrd для конкретной машины из 30-100 
модулей, так? Иначе зачем тогда делить их на куски? Это во-вторых. 
Предварительный анализ решения задачи "чего всё-таки выкинуть, а что 
оставить" (да, теперь проще от обратного отталкиваться) как раз 
показывает, что выкинув звук (3.6Мб), графику, итп. из 75Мб можно 
сэкономить "копейки". Потом кто-то захочет плимут и разумеется 
потребуется графика. Потом другому понадобится бульканье на этапе 
загрузки, и придётся включать обратно звук. В общем, мне пока не очень 
верится, что такой оптимизацией стоит заниматься без ущерба чему-то, 
когда речь об универсальной загрузке. А кейсы они бывают разные. Это 
в-третьих.

Предупреждая вопрос, модули (75Мб) -- фигня, в сравнении с фирмварью. 
Там ещё под 300Мб набирается. Конечно, можно сказать "идите на фиг" всем 
пользователям Wi-Fi, IB, или просто разделить на варианты "all" и "most".


> Поэтому нижеследующие выкладки абсолютно бессмысленны.
>

Поэтому в приведённом кейсе полторы секунды на очень быстрой машине 
вашего depmod -a превратятся в 20 секунд или даже в 2 минуты на старой 
мегатормозной лошадке. Ну, никто так не делает!


> Кроме того, я имел некоторый практический опыт по исследовательской 
> загрузке многих типов хостов - виртуалки, сервера, тощие клиенты 
> (включая допотопно-тормознутый Intel Atom) полным образом со всеми 
> четыретыщ модулей. Задержка при загрузке от depmod не ощущается вообще 
> никак, от слова "совсем", даже на вышуепомянутом атоме.
> Гораздо и неизмеримо большее время уходит на прокачать такой 
> бесмысленно-огромный образ по сети.
>
>> На конкретной системе из этих 75Мб или порядка 4450 модулей 
>> потребуется лишь 30-100 модулей.
>
> Именно, это типичное количество модулей, оказывающееся в итоговой 
> initramfs, буде она собрана из кусочков или из монолитного образа.
> И переживать по поводу скорости отработки на них depmod абсолютно 
> бессмысленно.

Если в итоговый образ попадёт 30-100 модулей, значит initrd собирается 
для конкретной машины, и смысл тогда делить его на куски? А если не для 
конкретной, я рассматриваю другой крайний вариант именно потому, что это 
наш случай (универсальная загрузка), и мы ещё не знаем, какие из модулей 
могут потребоваться. Их в конечном итоге потребуется те же 30-100, 
только заранее неизвестно, каких именно. Если сложить в initrd все 
имеющиеся, depmod -a должен будет пройтись сначала по всем условно 
4450-плюс-минус, и не мгновенно, а распаковав каждый.


>
>> При загрузке модулей, их распаковка выполняется автоматически. А 
>> теперь запустим depmod -a на максимально возможном наборе. Чтобы 
>> заглянуть в файл модуля, придётся его сначала распаковать, если не 
>> целиком, то хотя бы первый блок. И так по каждому из 4450 модулей, 
>> которые ещё неизвестно, потребуются или нет. gzip не умеет делать это 
>> во много потоков, только в один,
>
> Используйте pigz
>

Вы это не мне говорите, а на kernel.org предложите. Ядро же этим 
занимается. В деплое я и так его активно использую. :)


>>>> Так ничто не мешает сгенерировать компактный монолитный образ 
>>>> сейчас, не прибегая к модульности.
>>> Совершенно логически верное высказывание. Как и обратное - ничто не 
>>> мешает разбить функциональность по модулям сейчас, не прибегая к 
>>> монолитности.
>>
>> Пока что мешает отсутствие поддержки со стороны соответствующего 
>> инструментария. И кто его будет переделывать ради сомнительной (пока 
>> что) выгоды?
>
> Нет, отсутствие поддержки абсолютно не мешает использовать при желании 
> эту технологию уже сейчас, в режиме "заката солнца вручную". 
> Разумеется, поддержка в make-initrd по формированию отдельных образов 
> была бы конечно приятным бонусом по автоматизации, но она не обязательна.
>
> Равно как и обратное - наличие в природе такой технологии никому не 
> мешает жить по старому и пользоваться монолитными образами.
>

Вот на этой ноте хотелось бы спор закончить. Потому что, если не 
изменяет память, нынешний make-initrd позволяет буквально парой строк в 
/etc/initrd.mk создать initrd с нужным вам наполнением без единого 
модуля. А дальше -- каждый сам себе злобный Буратино! :) Делайте любые 
куски с наборами модулей и фирмварью, благо есть depinfo, который теперь 
и softdeps учитывает. То есть смысл дальше спорить, если нынешняя 
технология никак не мешает вашим экспериментам?


-- 
Best regards,
Leonid Krivoshein.

[devel] Fwd: Re: Модульный initrd.img

[Leonid Krivoshein]

Перешлю сюда, чтоб нить не потерялась...


-------- Перенаправленное сообщение --------
Тема: 	Re: [devel] Модульный initrd.img
Дата: 	Mon, 7 May 2018 11:42:09 +0300
От: 	Leonid Krivoshein <klark.devel@gmail.com>
Кому: 	Michael A. Kangin <mak@complife.ru>



07.05.2018 04:22, Michael A. Kangin пишет:
> On 05/07/2018 01:50 AM, Leonid Krivoshein wrote:
>
>>> Мне кажется, вы не вполне понимаете, о чём речь.
>>> Не стоит называть вызов depmod -a "автоугадавом".
>>> На паре десятков модулей в tmpfs он стремителен.
>
>> Ключевое здесь -- "на паре десятков". И эту пару десятков вы хотите
>> разделить на несколько отдельных initrd? :)
>
> Мне вновь кажется, что вы не совсем понимаете, о чём идёт речь.
>
>> Около 600Мб займёт генерируемый modules.dep, ещё более 700Мб
>> modules.dep.bin.
>
> Это вам со страху показалось.
>

Да, там Кб, а не Мб. 580Кб + 772Кб = 1.4Мб


>> Понятно, что на паре десятков модулей, да ещё и на быстром
>> процессоре, это может оказаться быстрее. Хотя 90% загрузка процессора
>> и в/в даже в этом случае не ускоряет процесс запуска машины, а
>> замедляет его.
>
> Я понимаю ваше нетерпение. Каждая сотая секунды на счету.
>
>> Под автоугадавом взаимных зависимостей модулей имелось ввиду брать не
>> дистрибутивное, а строить зависимости заново
>
> Вы описываете деятельность depmod крайне странными терминами.
> depmod не строит/перестраивает зависимости, а создаёт список
> зависимостей. И использует для этого не страшного Афтоугадава и прочую
> магию поней, а информацию из самих файлов модулей. Если есть сомнения,
> загляните в ман.

Вероятно Автоугадав здесь действительно не лучший термин, назовите его
Перестроителем или Построителем. :) На самом деле механизм
автоматического определения нужных модулей (страшный Автоугадав) большей
частью находится в самом ядре. И ему этот список зависимостей модулей в
определённый момент может потребоваться. Чтобы перестроить (создать
заново) список зависимостей, нужно как минимум линейно пройтись по всем
заголовкам модулей, как минимум рекурсивно по всей директории с модулями
ядра. Для экономии времени на этапе начальной загрузки каждый модуль
ядра у нас пожат отдельно gzip'ом, сам же слой с модулями не пожат. На
этапе начальной загрузки ещё неизвестно, какие из модулей реально
потребуются, какие нет. Полный набор модулей (без фирмвари) -- это
порядка 75Мб в сжатом виде. На конкретной системе из этих 75Мб или
порядка 4450 модулей потребуется лишь 30-100 модулей. При загрузке
модулей, их распаковка выполняется автоматически. А теперь запустим
depmod -a на максимально возможном наборе. Чтобы заглянуть в файл
модуля, придётся его сначала распаковать, если не целиком, то хотя бы
первый блок. И так по каждому из 4450 модулей, которые ещё неизвестно,
потребуются или нет. gzip не умеет делать это во много потоков, только в
один, отсюда и 90% загрузки CPU. На моём 8-ми ядерном топовом Intel NUC
с 2xNVME в raid-0, 32Гб RAM и Core i7 циферки уже другие:

cd /lib/modules/`uname -r` && time depmod -an | wc -l

0:01.29elapsed 74%CPU
113512inputs + 0outputs
39155

На эти полторы секунды машинка взревела. Заметьте, даже в файл не
вывожу, только подсчитываю строки. Повторный запуск, когда все данные
уже в кэше? Да, немного меняют картину, но очень немного!

0:00.93elapsed 99%CPU
0inputs + 0outputs
39155

И это очень шустрая машинка, а представляете тормоза для большинства
более медленных машин? Речь пойдёт не о 1-1.5 секундах, а каждая секунда
на этапе начальной загрузки сами знаете на вес чего. :)


>
>> этот процесс вынуждено выполняется на этапе make-initrd, потому что в
>> образ попадают не все модули. Ваш модульный подход вынуждает
>> переносить перестроение зависимостей на этап загрузки, если модули
>> разложены по разным кускам.
>
> Ага, целая сотая доля секунды вынужденного "перестроения
> зависимостей". Меньше деления не нашлось, извините.
>

Всё зависит от скорости конкретной машины и обрабатываемого набора
модулей. А также того факта, пожаты они или нет, каким упаковщиком.


>>> 0.00user 0.00system 0:00.01elapsed 90%CPU (0avgtext+0avgdata
>
>
>> Так для реальной жизни в меню только те варианты, которые нужны. Ну и
>> что, что есть пересечения по части сжатых initrd. Их куча устаревших
>> всё равно на дисках валяется без надобности. Вы знаете много людей,
>> которые пользуются remove-old-kernel? :)
>
> Я глубоко уважаю право некоторых людей без надобности держать у себя
> на дисках кучу устаревших initrd.
>
>
>> Так ничто не мешает сгенерировать компактный монолитный образ сейчас,
>> не прибегая к модульности.
>
> Совершенно логически верное высказывание. Как и обратное - ничто не
> мешает разбить функциональность по модулям сейчас, не прибегая к
> монолитности.

Пока что мешает отсутствие поддержки со стороны соответствующего
инструментария. И кто его будет переделывать ради сомнительной (пока
что) выгоды?


> Я тут подумал - даже поддержка depmod со стороны initrd не нужна. Эту
> depmod и дёргающий её скриптик тоже можно притащить сторонним модулем.
> Надо будет еще подумать, мне понравилось. Захват initrd на абордаж!


-- 
Best regards,
Leonid Krivoshein.