From: Leonid Krivoshein <klark.devel@gmail.com> To: devel@lists.altlinux.org Subject: Re: [devel] Модульный initrd.img Date: Tue, 8 May 2018 02:34:26 +0300 Message-ID: <acdc59b7-ecb9-6c49-d6f4-aee82324c022@gmail.com> (raw) In-Reply-To: <eba02d9e-5644-5b24-10f3-fadebf8359b8@complife.ru> 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.
next prev parent reply other threads:[~2018-05-07 23:34 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-06 16:55 Michael A. Kangin 2018-05-06 18:25 ` Leonid Krivoshein 2018-05-06 19:34 ` Michael A. Kangin 2018-05-06 23:50 ` Leonid Krivoshein 2018-05-07 11:52 ` Michael A. Kangin 2018-05-07 23:34 ` Leonid Krivoshein [this message] 2018-05-07 22:56 ` [devel] Fwd: " Leonid Krivoshein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=acdc59b7-ecb9-6c49-d6f4-aee82324c022@gmail.com \ --to=klark.devel@gmail.com \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git