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=05EHCNX7Vn0Ajn3w3nwOMF5vvkWVlhlvX+/g7F+WdH4=; b=CadHHvuw0W3ZTMejxRFs/ivimiBy2c1W+wp47nQmuwb+xSN9hKadOfxCbfmRGCa/QI wyA5k6F7eVxA3TLj1Twqz85N5WJQnSOIKTh573RfNE7FnvgoWsoa6MlYJwFR2rP956kJ /o7i5ce4GfTo/A9Zc+C2sIpQagAUavXSFiziGj/KguqyQN1kTnmkEHBzmfs2AjlFPX7a pKHCerQOmupZlCNpB3VlUnqULfm+3v8bF58/g6bSKm1/W97w/7rXxo17HHNH/rdsWQnK i1njgIiUcMIUv8fG6aO1WZMBLCEO2awgwjAPgWhA0wXMyBICXTPh/QZXPge/E1WHeCoC XwXQ== 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=05EHCNX7Vn0Ajn3w3nwOMF5vvkWVlhlvX+/g7F+WdH4=; b=m6FcE0soZsKLV1PqeoLLDZ0jNefL6/bxTAdzlzS8yOum/rlNU6WbIQgdWdtOdi90G8 cKUc/A+1lZNlq7JgTXHXnwgTS4HuCIgmL24GpERnMk7BZFTufCQ6rDKiFNZaXZ1LkPrY f6RJ31nelFu2ykoNP0AvzljytSR2qH5eHEk3JSr5R9IfTGAFVx0r++wkrRjt6TFwWLWj lgNL8xkBoTYRzAUf1uxFFLZNS1CZUaAP48FjtS+EoSpC5jO9b8zuL4eZrIZnJvwvfLQe fE71n7MYxgBswUcJUSEqYGo80MRZvZl4QKBbDwnhMMi5OFPp3wQT4pe7QYpKYaugreB9 QgZQ== X-Gm-Message-State: ALKqPwcxydP6/SQGN1Ud5hNluNanNxupJWuhoxvovzwoNxavnHIGFwC0 Gps5TZy8ygMFGWUsUncqSJf2LQ== X-Google-Smtp-Source: AB8JxZostJy1+j1MEAufrtvw24YdlL4e7Il22TO6VndtCBnNEM3dPgx84cSQZg7Vy4D7hN98uQfsLA== X-Received: by 2002:a19:1498:: with SMTP id 24-v6mr4432464lfu.128.1525650651807; Sun, 06 May 2018 16:50:51 -0700 (PDT) To: devel@lists.altlinux.org References: <61310192-890b-1f93-a05c-09afb4a8efdd@gmail.com> <38eee31c-3666-461f-1c1b-0a23a5064ef1@complife.ru> From: Leonid Krivoshein Message-ID: Date: Mon, 7 May 2018 02:50:50 +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: <38eee31c-3666-461f-1c1b-0a23a5064ef1@complife.ru> 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: Sun, 06 May 2018 23:50:53 -0000 Archived-At: List-Archive: List-Post: 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.