[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.