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

[Leonid Krivoshein <klark.devel@gmail.com>]

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


-------- Перенаправленное сообщение --------
Тема: 	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.