From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 12 Apr 2018 23:09:24 +0300 From: Michael Shigorin To: devel@lists.altlinux.org Message-ID: <20180412200924.GF8063@imap.altlinux.org> References: <20180412174627.GA5465@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180412174627.GA5465@dad.imath.kiev.ua> User-Agent: Mutt/1.5.23.88.hg577987ca2d02 (2014-03-12) Subject: Re: [devel] I: [[Girar/Parallel]] 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: Thu, 12 Apr 2018 20:09:25 -0000 Archived-At: List-Archive: List-Post: On Thu, Apr 12, 2018 at 08:46:28PM +0300, Igor Vlasenko wrote: > оформил цикл писем по улучшению сборочницы в страничку > https://www.altlinux.org/Girar/Parallel Спасибо! Так получилось наконец прочесть эту сагу (заодно повоевал с лишними запятыми и отформатировал). --- Про уменьшение Tm ещё продумываются софтовые меры (патчилка индексов имени at@) и аппаратные (машинка с процессором вида "меньше, да быстрее ядер" и SSD). >>> чтобы не тормозить сотни тысяч ради одного У нас, к сожалению, не так редок "научный" подход к решению задач вместо "инженерного" -- например, каждому hello резервируются ресурсы, достаточные для сборки boost или LO. Это при том, что несложно фиксировать CPU/RAM/time по опыту предыдущих сборок и неожиданности обрабатывать как исключения. Проблема "всего лишь" в том, что никто до сих пор не взялся ещё и такое сделать, развернуть и отвечать за результат. Есть ещё идея, которую можно условно назвать "hasherd": когда задачи не распихиваются по исполнителям, а разбираются ими из очереди (заодно так должно стать удобней и маневрировать мощностью, и делать её сильно неравномерной -- например, держать узлы с множеством более медленных ядер и с меньшим количеством более быстрых ядер, аналогично по памяти; всё это может особенно сильно проявиться на не-x86, как мне кажется). >>> В импорт только Mass_Rebuild и попадает? Конкретно федорины mass rebuild, которые являются предельно топорным методом решения той же задачи, что у нас решена пусть и не идеально, но куда технологичней -- и впрямь не хочется видеть ни в репо, ни в %changelog (это и sisyphus-cybertalk@, и выхлоп apt-cache show -- волны от кирпича круглые, однако). И у этой оптимизации есть большой плюс: для неё никого ждать не надо. :) >>> "Уже сейчас сборочница иногда простаивает [...]" Это же типовая проблема массового обслуживания -- вспомните, как под новогодние куранты дружно ложилась сотовая сеть. Отвыкли? Вот Игорь хочет и со сборочницей отвыкнуть. Ну и да, средняя пропускная способность московских дорог весьма высока, но почему-то водилы жалуются на пробки: возможно, им хотелось бы более высокой _пиковой_. >>> [install check] По сути-бесполезная проверка Скорее "слишком дорогая для синхронной", но ловившая, насколько знаю, реальные ошибки. Возможно, такое достаточно делать асинхронно и _обязательно_ параллельно (см. выше про hasherd) на первичных архитектурах. >>> К примеру, чтобы выполнить тест на символы в бинарниках, >>> надо распаковать rpm Угу, а при сборке он у нас ещё вообще не запакованный есть -- бери списки файлов из заголовков только что собранных бинарных пакетов да выгребай содержимое из %buildroot (заодно можно другим хукам отдавать вроде приёмных скриптов prometheus, но тут важно не переоптимизировать до слишком тесной связности). --  ---- WBR, Michael Shigorin / http://altlinux.org   ------ http://opennet.ru / http://anna-news.info