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