From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 27 Apr 2020 11:11:42 +0300 From: Michael Shigorin To: devel@lists.altlinux.org Message-ID: <20200427081142.GD7900@imap.altlinux.org> References: <20200425214614.GA7859@gyle.altlinux.org> <20200426142052.GA14178@altlinux.org> <20200426143524.GA9098@imap.altlinux.org> <20200426153346.GA14939@altlinux.org> <20200426185427.62b74d36127d6f395f2f7fc4@altlinux.org> <20200426173644.GA16279@altlinux.org> <20200427094546.aac3ae0255ebe893ae997c9c@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200427094546.aac3ae0255ebe893ae997c9c@altlinux.org> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [devel] =?koi8-r?b?0NLPIHRleGxpdmUgySBpbnN0YWxsY2hlY2sg1NnT0d4g?= =?koi8-r?b?0M/E2sHEwc7Jyg==?= 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, 27 Apr 2020 08:11:43 -0000 Archived-At: List-Archive: List-Post: On Mon, Apr 27, 2020 at 09:45:46AM +0300, Andrey Savchenko wrote: > > > Реальная причина проблем: > > > неэффективно реализованный install check на нашей сборочнице В смысле последовательный, что в случае мегазаданий вроде kde или python явно также не идёт на пользу. Понятно, что сейчас это архитектурное ограничение; жаль, что уже в эпоху не просто SMP, а многоядерных процессоров решили сделать так, но бывает. Кстати, ещё одно припоминается из тех обсуждений и своих наблюдений: растущее как бы не экспоненциально время добавления подзаданий в большое задание (вспомнил недавно на php7, когда смотрел за этим, а не запустил скрипт и переключился на другой десктоп -- первая "мелочь", кроме самого php7, добавляется быстро, затем на глазах происходит плавное замедление по пути к последним подзаданиям). > > Не понимаю, о чём идёт речь, install check включён на всех > > архитектурах. Разве на aarch64 был включён и на ThunderX? Не помню точно, но вроде тогда включать не стали. (а если стали -- Черепанов, поди, передаёт приветы) > > Если речь идёт про ваш e2k, то чем меньше вы будете говорить, > > что вы там ещё отключили, тем менее плохо мы будем о вас думать. Ну почему, временно(tm) отключенная ручка doc/docs/apidoc не только оставила нас без порой полезного, но и вскрыла некоторое количество разнокалиберных ляпов в спеках. (понятно, что давным-давно пора её включать и чинить, если что не станет собираться теперь -- этому сильно мешала питонятина со sphinx, ныне побеждённая) > Install check там выключен по одной простой причине: там DDR3 > память, которая не справляется с вашим якобы корректно > работающим install check за разумное время. DDR3 и на basalt, например -- она умеет работать быстрее. На наших текущих сборочных узлах e2kv4 DDR3-1333 выдаёт примерно до половины своей пиковой полосы пропускания, которую я видел на x86_64 (правда, экстремально выжатых). Там, как и на ThunderX, явно даёт знать ещё один вопрос: ядер достаточно много, но каждое из них относительно x86_64 на задачах распаковки пакетов выходит существенно медленней. > Вот и возникает вопрос в целесообразности таких проверок. > Тем более, что много раз обсуждалось как можно улучшить эту > проверку, но никому нет дела. Насколько понимаю по обсуждениям переделки сборочницы -- дело есть, просто нетривиальное весьма. > > viy@ можно и нужно много за что сказать спасибо, но за > > нынешний texlive у меня язык не повернётся поблагодарить. > Ваши предложения? Давайте я скажу. Дима, если тебя устраивал второй вариант с мелкой порезкой, который Игорь собирал своей сборочницей -- ну так обеспечь возможность прохождения такого в сизиф, много у кого язык сразу повернётся поблагодарить вас обоих ;-) --  ---- WBR, Michael Shigorin / http://altlinux.org   ------ http://opennet.ru / http://anna-news.info