From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FUZZY_XPILL autolearn=no autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=CxSA5YRYFxLj8CIA/kOMmyDtgrG+m210uLBwl8wW+lc=; b=Z6oTPNd7WEu2gukDWWD5UK8Ms06J1a0zF25U2ap/O6A67yJVSwtwjJg+gwTB2+7uC7 GrLTyy0eKHLNFUNS55oRvtTMX57aHaSdJCj3//CfXNxG9012cDd0TUndhcgpkycfju8J L67cDQ0beokt3aA3LOOb87OwqK4MiOYAnFTABzcgud8ItWeEZErv2wIfTiVVrh6L02gD 06JDRk2QNd2fKSkLmqs6+tNioOhIBUK38DRk9kI6q2ynmpbALzQLQ5anz5of9qNXqXY2 JCyQ8LbrewMgweUAMnsIajweCPOTtiwVQZ3mx2soVxKzeM3jozrGiztVZo40jwpjD0yZ tDqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CxSA5YRYFxLj8CIA/kOMmyDtgrG+m210uLBwl8wW+lc=; b=CWyGaaoxFR3dXsT3YNBNCIbQeeEARdXM4HUWpV4DCzL5Twc9SIGPEtUGVPmszKAH9u q9zKMSL4uAM15t2ArwppD23uL5to8CSwFdMfdXSSWUXjea+7myEsYrT0jLfhzTBbeuzk BOxMGbaPQ0wfmy/LuBnQEfk5PrExDuUfs+OD9GZFG/cR5EHU2NI7DGRlOOGa0/LCRQhl mtcM4NCeKOayg+tzDWQAqLKtixoFhyyFhNvm+gTbFtv1Pb5caCk65N4jQ5C+fjZMEK0d Mk4TfcpRpXYE16ytl5EE2MDo337l+h6rHfFW0mGvtDnEWELR4Cla1KLbKl3j2S88L8Vm GFWQ== X-Gm-Message-State: ALQs6tADDwt2tLB+ln/R5LqjNx0N6DriESLLic184LOA/NcuGn9LEMo0 qM/z5rGv6nqQYRwVoPpTcA+NDg== X-Google-Smtp-Source: AB8JxZr7iocKWQTnLzNOsQspbNW4/Ja2Yf1BDMNR/B1uLYPQ39XS8hnV0uvrhRnsdLVqIS/LyzOsQw== X-Received: by 2002:a2e:83d7:: with SMTP id s23-v6mr14959202ljh.34.1525736068217; Mon, 07 May 2018 16:34:28 -0700 (PDT) To: devel@lists.altlinux.org References: <61310192-890b-1f93-a05c-09afb4a8efdd@gmail.com> <38eee31c-3666-461f-1c1b-0a23a5064ef1@complife.ru> <3811d2e4-d1e1-8bab-b07d-ba23e15035f0@complife.ru> <3f73de94-85d8-9f69-c42e-4bf793c16cd6@gmail.com> From: Leonid Krivoshein Message-ID: Date: Tue, 8 May 2018 02:34:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?0JzQvtC00YPQu9GM0L3Ri9C5IGluaXRyZC5pbWc=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 23:34:30 -0000 Archived-At: List-Archive: List-Post: 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.