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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=9YMtDBcpwU1xi+7W3MM9TNvIsNy5t2PrWvAhlEryf3U=; b=ZZYvh6qcwUkGISPobdS29SoMHvYeveZCZSLXunI4O1d2RSSpXwPFMeOl37xavovUak VGz1kUrjWMmFV5wCZxyzzTRg2Rn3djW0BZf8twXdDUL0gnDZEZapiyJ9941kSR6pQpCQ 5uWtnHB63DnuwJ+kfsAYk8Gm6O5ieTpHos4kmbmR1DeqqRHlLiE4jvj950heW4mISL7/ Wm+NEJxQ+aXheKjAOv2QxZo5252PEAx1Pl15apfpCzL7fcsC9PF4BiFHEE2YpVEwW6Pa JnpeJ2RgwmHxiUl09fwfNZ2+ImQNhJRnjluFN8Sg46K+RGLJiOTh/qN1OyMbskk2hKAC avqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9YMtDBcpwU1xi+7W3MM9TNvIsNy5t2PrWvAhlEryf3U=; b=ShfEHp6U2lWSPM4esbnnIWEmrUQxFXXCvFT2iNgIvIQMiScs5e9NwWadFVyDgshV7P ztFhW8+87sBzFZXa4tyhG7aOa7JgG6IiSz+gfr0zW+HXYp3AZFd13zqF6kWUiaeTj7bY l+WG2JLm0EgNgiXXNK3SXG5wJCT13e/OUbVAt9MVZ0eYLk+KkIYby2r6JpS+71WlWW+/ qGzqU5PUxxIc2XF0R0daFrwA9+GV8kCFgcwP5BQ/hwIdYeAFwMIVS2kw40/waqIMMxBl JKu+yG34HtHf3UrlLXidc8CUwV3ngaaOdDpVSA7BKKttIykH9fHn0rsuTPbMl7M5w5Dr 79hg== X-Gm-Message-State: ALQs6tBvMyPFA7v7ftu1PG4wN50xv7Mu27ZD8vrb2/Gnr+OxMiqyqcbe P8RjjGrKOKex9NQZUBqaT6gdCA== X-Google-Smtp-Source: AB8JxZpXshY4UVw3pXPiIJe8eWv0ZvCjUzdpRNdmXYvooxDMEutSKljZWBT9TPOl2Hug0lfhbzLRZQ== X-Received: by 2002:a19:9389:: with SMTP id w9-v6mr24000487lfk.75.1525733809649; Mon, 07 May 2018 15:56:49 -0700 (PDT) References: <3f73de94-85d8-9f69-c42e-4bf793c16cd6@gmail.com> To: ALT Linux Team development discussions From: Leonid Krivoshein X-Forwarded-Message-Id: <3f73de94-85d8-9f69-c42e-4bf793c16cd6@gmail.com> Message-ID: <35b8473d-0f92-d3d6-0306-b29898b8a1d2@gmail.com> Date: Tue, 8 May 2018 01:56:48 +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: <3f73de94-85d8-9f69-c42e-4bf793c16cd6@gmail.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Subject: [devel] =?utf-8?b?RndkOiBSZTogINCc0L7QtNGD0LvRjNC90YvQuSBpbml0?= =?utf-8?q?rd=2Eimg?= 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 22:56:52 -0000 Archived-At: List-Archive: List-Post: Перешлю сюда, чтоб нить не потерялась... -------- Перенаправленное сообщение -------- Тема: Re: [devel] Модульный initrd.img Дата: Mon, 7 May 2018 11:42:09 +0300 От: Leonid Krivoshein Кому: Michael A. Kangin 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.