40618 pgo 2021-07-30 23:35:23 +0300 Enable build with PGO (profile-guided optimization) 2021-08-01 19:06:03 +0300 1 1 4 Development Sisyphus rpm-build unstable x86 Linux NEW P5 normal --- 1 vt placeholder arseny glebfm imz iv ldv vt qa-sisyphus oldest_to_newest 201098 0 vt 2021-07-30 23:35:23 +0300 Некоторые пакеты выиграют от сборки с 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 201116 1 vt 2021-08-01 00:55:10 +0300 Есть идея делать %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 или без. Ну или управлять этим через макрос.) 201123 2 imz 2021-08-01 19:02:07 +0300 (Ответ для 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. 201124 3 imz 2021-08-01 19:06:03 +0300 (Ответ для Ivan Zakharyaschev на комментарий #2) > /feedback/for-SRPMNAME/from-GENERATOR1/* > /feedback/for-SRPMNAME/from-GENERATOR2/* > ... > > Там можно сделать перед использованием на втором прогоне gcov-tool --merge > разных источников информации. gcov-tool merge сливает пары (этого достаточно, чтобы слить и большее множество).