[devel] многопоточная сборка

Michael Shigorin mike на altlinux.org
Чт Апр 4 01:32:37 MSK 2019


On Wed, Apr 03, 2019 at 08:44:02PM +0300, Dmitry V. Levin wrote:
> On Wed, Apr 03, 2019 at 07:09:35PM +0300, Michael Shigorin wrote:
> > python-module-lxml: 26005 99%
> $ grep -F 'elapsed ' beehive/logs/Sisyphus-x86_64/latest/success/python-module-lxml-4.3.3-alt1 
> 320.74user 8.13system 8:26.12elapsed 64%CPU (0avgtext+0avgdata 823328maxresident)k
> 330.41user 11.94system 9:13.28elapsed 61%CPU (0avgtext+0avgdata 823328maxresident)k
> На sisyphus_e2k сборка действительно заняла на два порядка
> больше времени, чем на x86?  Прискорбно.

Да.  Возможно, об этом надо будет повесить отдельный баг.

> > ...из разбора архива заданий для sisyphus_e2k...
> > wesnoth1.12: 24803 99%
> Такого пакета в Сизифе нет.

Архив заданий помнит уже много чего даже тут. :)

> У ближайшего родственного [...]wesnoth-1.14.5-alt2 264%CPU
> сборка выглядит распараллеленной.

Уже радует; хотя пока в процессе сборки наблюдаю скорее единичку,
scons может игнорировать явно заданное -jN?

e804:~> rpm --eval %{?_smp_mflags}
-j32

Надо будет глянуть, не лучше ли покажет себя cmake, который там
тоже в спеке поддержан (но не по умолчанию).

> > samba-DC: 16774 94%
> Такого пакета в Сизифе нет.

Да, их наконец опять объединили.

> > samba: 14355 94%
> [...]samba-4.10.0-alt1 214%CPU
> Сборка выглядит распараллеленной.

Отлично.

> > jfreechart ждёт оптимизированной jvm
> > jfreechart: 10732 88%
> На sisyphus_e2k сборка действительно заняла на два порядка
> больше времени, чем на x86?

Да.

> Вряд ли кто-то затратит много сил на распараллеливание сборки
> пакета, который собирается за 2 минуты.

Там дело в zero vm пока, потому и написал особую оговорку.
Хотя на mipsel примерно так и останется, насколько помню.

> > Mesa: 10110 96%
> Mesa-4:19.0.1-alt1 407%CPU
> Сборка выглядит распараллеленной.

Отлично.

> > python-module-numpy: 7346 98%
> $ grep -F 'elapsed ' beehive/logs/Sisyphus-x86_64/latest/success/python-module-numpy-1:1.15.4-alt1 
> 524.30user 22.10system 18:10.31elapsed 50%CPU (0avgtext+0avgdata 381712maxresident)k
> 554.33user 27.57system 19:24.89elapsed 49%CPU (0avgtext+0avgdata 381712maxresident)k
> На этот пакет предлагаю повесить баг.

https://bugzilla.altlinux.org/show_bug.cgi?id=36500

Не очень-то разогнался по сумме, но всё же:
115% cpu 8:16,42 total
(x86_64, для e2k нужен ещё небольшой archdep patch)

> > bouncycastle: 6833 99%
> Сборка выглядит слегка распараллеленной.
> Кроме того, пакет выглядит импортным.

А ещё это java.

> > chicken: 6529 97%
> $ grep -F 'elapsed ' beehive/logs/Sisyphus-x86_64/latest/success/chicken-4.1.0-alt2.1 
> 320.75user 10.16system 11:09.34elapsed 49%CPU (0avgtext+0avgdata 309292maxresident)k
> 325.33user 12.28system 11:27.10elapsed 49%CPU (0avgtext+0avgdata 309292maxresident)k
> На этот пакет предлагаю повесить баг.

https://bugzilla.altlinux.org/show_bug.cgi?id=36501

Судя по федоре, 5.0.0 тоже собирается только однопоточно:
https://src.fedoraproject.org/rpms/chicken/blob/master/f/chicken.spec

С объездом а-ля %make_build || make собрался на x86_64
заметно быстрей: 1:30.79elapsed 366%CPU

Применяем?

> Мораль: привлекать внимание коллег нужно, но для этого следует
> использовать релевантные данные.  Как мы видим, релевантность
> данных с sisyphus_e2k в данном примере составила 20%.

Я мог убрать java-пакеты, но решил оставить честный head
и не стал убирать тот же lxml, с которым заведомо ничего
так просто не сделать.  Ещё хорошо бы добавить данные по
acl для удобства грепанья -- поделишься тем скриптиком?

> Целесообразнее использовать данные тестовой пересборки Сизифа.

Их у меня под рукой вроде бы нет, но затем и предложил в качестве
затравки хотя бы такие скрипты для их разбора. :)

После завершения основных работ по обновлению sisyphus_e2k
поближе к sisyphus/p9 можно будет сделать набег по ним уже
без архива.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info


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