[devel] про texlive и installcheck тысяч подзаданий

Michael Shigorin mike на altlinux.org
Пн Апр 27 11:11:42 MSK 2020


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


Подробная информация о списке рассылки Devel