Bug 40618 (pgo)

Summary: Enable build with PGO (profile-guided optimization)
Product: Sisyphus Reporter: Vitaly Chikunov <vt>
Component: rpm-buildAssignee: placeholder <placeholder>
Status: NEW --- QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: arseny, glebfm, imz, iv, ldv, vt
Version: unstable   
Hardware: x86   
OS: Linux   

Description Vitaly Chikunov 2021-07-30 23:35:23 MSK
Некоторые пакеты выиграют от сборки с PGO (profile-guided optimization). Такая сборка есть в некоторых дистрибутивах (clearlinux) и уже есть в некоторых пакетах в ALT.

Общая задача, чтоб на неё ссылаться.

[1] https://en.wikipedia.org/wiki/Profile-guided_optimization
[2] https://lwn.net/Articles/830300/ Profile-guided optimization for the kernel
Comment 1 Vitaly Chikunov 2021-08-01 00:55:10 MSK
Есть идея делать %prep + %build да раза, первый раз в optflags добавляется:

  -fprofile-generate -fprofile-dir=/tmp/pgo -fprofile-update=atomic

второй раз:

  -fprofile-use -fprofile-dir=/tmp/pgo -fprofile-correction

+ между ними делается find /tmp/pgo -name '*conftest.gcda' -delete.

Для профилирования используется или %check, или можно сделать макро %profile_use_exit, которое помещается в конец %build перед генерацией профиля - в первом проходе он не делает ничего, а во втором exit 0.

Идея Глеба - дополнить spec секцией (скажем) %profile_generate, где находится скрипт генерирующий профиль и само наличие этой секции запускает двойной build с PGO.

(В ней можно было бы, например, задавать и тип PGO с -fprofile-partial-training или без. Ну или управлять этим через макрос.)
Comment 2 Ivan Zakharyaschev 2021-08-01 19:02:07 MSK
(Ответ для Vitaly Chikunov на комментарий #1)
> Есть идея делать %prep + %build да раза, первый раз в optflags добавляется:
> 
>   -fprofile-generate -fprofile-dir=/tmp/pgo -fprofile-update=atomic
> 
> второй раз:
> 
>   -fprofile-use -fprofile-dir=/tmp/pgo -fprofile-correction
> 
> + между ними делается find /tmp/pgo -name '*conftest.gcda' -delete.

(Погуглил: это какие-то особые файлы, которые мешают второй стадии.)

> Для профилирования используется или %check, или можно сделать макро

Я ещё подумал о получении feedback для второй сборки извне (из girar) и запуск второй сборки тоже извне.

При первом прогоне некоторые rpm собираются для профилирования, т.е. негодные для публикации. Потом всякие install check-и сохраняют информацию из обговоренного места (типа /feedback/for-SRPMNAME/*). Делается второй прогон (итерация задания, где должны ещё собираться пакеты, которым это требуется), во время которого подкладывается собранная информация. Она может быть из нескольких источников (install check разных бинарных пакетов и вообщеоткуда угодно при желании), так что её надо разложить как-то так:

/feedback/for-SRPMNAME/from-GENERATOR1/*
/feedback/for-SRPMNAME/from-GENERATOR2/*
...

Там можно сделать перед использованием на втором прогоне gcov-tool --merge разных источников информации.

Возникает мысль, что для воспроизводимости сборки нужно эту использованную информацию (профиль) сохранить рядом или внутри src.rpm. Только внутри сложно, потому что тогда меняется id src.rpm, да и для разных архитектур она разная. (Ну при желании использовать для этого формат src.rpm, понятный rpmbuild, можно хранить общий для всех архитектур оригинальный src.rpm, и для каждой архитектуры ещё свой с дополнительной информацией, можно без тех Source, которые есть в оригинальном, т.е. nosrc.rpm.)

* * *

У меня раньше были мысли о механизме feedback из girar для второй окончательной итерации сборки в связи с желанием исключить из Provides неимпортируемые python3-модули, так чтобы лишний раз не напрягать мейнтейнеров (автоматическая вторая итерация), но и не раздувать сборочную среду (BuildRequires), усложняя граф сборочных зависимостей циклами, поэтому не делать это полностью внутри одного запуска rpmbuild.
Comment 3 Ivan Zakharyaschev 2021-08-01 19:06:03 MSK
(Ответ для Ivan Zakharyaschev на комментарий #2)

> /feedback/for-SRPMNAME/from-GENERATOR1/*
> /feedback/for-SRPMNAME/from-GENERATOR2/*
> ...
> 
> Там можно сделать перед использованием на втором прогоне gcov-tool --merge
> разных источников информации.

gcov-tool merge

сливает пары (этого достаточно, чтобы слить и большее множество).