[devel] IХ. Алгоритмы работы сборочницы. O commit. ч.1

[devel] IХ. Алгоритмы работы сборочницы. O commit. ч.1

[Igor Vlasenko]

Уважаемые господа!

Продолжаю цикл писем, посвященный предложениям по улучшению
нашей сборочницы.

Письма I - VIII можно посмотреть здесь:
  https://www.altlinux.org/Girar/Parallel

Письмо IХ. Алгоритмы работы сборочницы. O task merge (commit). ч.1
-------------------------------------------------

task merge - это операция, которая получает из репозитория R_n
и собранного таска B новый репозиторий R_{n+1}.

R_n + B -> R_{n+1}

На этапе task merge в параллельной сборочнице у нас
возникает проблема, которой в последовательной сборочнице не было.
Таск B был, вообще говоря, собран не с текущим репозиторием R,
а с каким-то более старым репозиторием R_k,  k <=n.
Таск B прошел проверки целостности для R_k,
но у нас теперь R_n и B может иметь, к примеру, unmets.

Что наша сборочница должна делать на этапе task merge?
Она должна повторить проверки целостности для B, но
уже на R_n. Если B проходит проверку, делаем commit
и получаем новый репозиторий R_{n+1}.
Иначе возвращаем B в очередь build, на пересборку с R_{n+}.

Что наша сборочница делает, но делать этого не должна,
против чего я выступаю?

Сборочница просто берет и принудительно пересобирает B на R_n.
Да, там есть оптимизация - если сборочное окружение пакета
не изменилось, то его пересборка очевидно избыточна,
и тогда B коммитится без пересборки, что иногда ускоряет
сборочницу.
Однако по сути для не test-only пакетов это та же последовательная
сборочница. Привязка commit к повторной пересборке
является в ней узким местом.

И не просто узким в процентах, а узким местом в абсолютных
величинах, т.е. есть определенный порог, число пакетов,
которые такая сборочница способна обработать в сутки.

По достижении этого порога сборочница просто захлебнется.
Но сначала резко увеличится среднее время ожидания
до попадания пакета в сизиф, пакеты начнут стоять в очередь
на commit часами, потом сутками,
появятся AWAITING 1.12, AWAITING 1.18 ...
начнется грызня, обвинения, что кто-то заливает слишком много пакетов,
придирки, что пакет залит по недостаточно важной причине,
рулеж очередью пакетов вручную,
попытки усложнить майнтайнерам доступ к commit
(сейчас вот появилась опция --commit, однако ее
легко заскриптовать; скоро против этого, боюсь, в сборочницу
и ssh капчу начнут встраивать :)

Если не прекратить это безобразие, и не исправить проблему
в корне, т.е. не распрямить кривизну в алгоритмах,
то мы скоро придем к тому, что на доступ к сборочнице
талоны будут выдавать.

Теперь я хотел бы пояснить, что я понимаю под
кривизной в алгоритмах.

Сама по себе пересборка - вещь достаточно полезная,
если ее применять правильно.

Дмитрий и Алексей писали о ее полезности:
at@:
 unmet - это влияние, которое удалось формализовать. Это счастливый
 случай, когда в черный ящик удается воткнуть предметную проверку. Но
 все влияния формализовать очень тяжело. Например, неизвестно даже,
 соберется ли пакет с новой библиотекой, и достаточно ли новая
 библиотека совместима со старой, чтобы пытаться протащить в
 репозиторий таск, собранный со старой библиотекой.

 Выход мне кажется концептуальный только один: строгая сериализация
 транзакций. Каждый таск начинает собираться на свежем состоянии
 репозитория и порождает следующее состояние.

ldv@:
 Уточню: я считаю очевидным, что если сборочная среда пакета в задании
 изменилась, то этот пакет подлежит пересборке.  Если пакет в результате
 пересборки изменился, то все касающиеся его тесты подлежат перепроверке.

 Более того, я считаю очевидным, что если свежесобранный пакет входит в
 сборочную среду других пакетов, то все они должны быть незамедлительно
 пересобраны и перепроверены.  К сожалению, это у нас ещё не реализовано.

Я с этим, в принципе, согласен, если
1) речь идет о корректно реализованной пересборке и
2) мы потянем требуемые для этого ресурсы.

К примеру:
Пришла в Сизиф новая libpng, и пересобрали все "затронутые" пакеты.
Пришел в Сизиф новый gcc, и пересобрали все пакеты, собиравшиеся
старым gcc.

Здесь есть подводные грабли, которые нужно обходить очень деликатно.
Первое, это циклы зависимостей.
Пересобрали foo, затронут bar. Пересобрали bar, затронут foo.
Нужно не пересобирать цикл бесконечно, а остановиться
после 1-2 пересборок.
Для этого нужна хоть простая, но БД, где будет храниться состояние.
Заодно, можно оптимизировать пересборку, откладывать ее подольше,
чтобы очистить одной пересборкой сразу множество поводов.

Второе, это ресурсы. Обновление пакетов в Сизифе может оказаться
слишком дорогостоящим, ведь два пакета до и после пересборки бинарно
разные, их не схардлинкуешь и архив Сизифа начнет резко дуться.
Новый месяц - новый винт, раз в квартал к этим винтам
надо докупить серверок, через пару лет докупить СХОДик,
чтобы было куда сервера ставить. Потянем такое?

Чтобы таких вещей не было, пересборка должна быть умной.
К примеру, сколько пакет с фотообоями на рабочий стол не пересобирай,
ни резкость на картинке не улучшится, ни яркость не добавится.

Или скриптовые модули, к примеру, rubygems.
Там основная часть работы rpm
состоит из вызова tar -x ; /usr/bin/install; tar -c.
Имеет ли смысл их пересобирать __ в Сизиф __ ?

Просто пересобирать их в сторонке, в Beehive, конечно, стоит.
Слом сборки, изменения в requires ...
Все это важные симптомы, с которыми надо разбираться.

Но в остальных случаях для таких пакетов пересборка будет будет
очевидно бессмысленной.
Или java. Там есть компиляция, но это язык для кодеров за еду,
и с защитой от кодеров за еду. Там нет макросов и 
проблемы там устроены так, что пересборкой не лечатся.

В итоге надо либо писать сложный умный код,
делающий редко, но метко умные вещи,
либо делать что-то более тупое, но не слишком затратное,
вроде "полная пересборка раз в полгода-год"

Такое, да, было бы полезно.
Но что мы видим у нас? Делает ли сборочница такую пересборку?
Очевидно, нет.

К примеру, приходит в Сизиф новая libfoo. Свежесобранный
пакет входит в сборочную среду сотен других пакетов.
unmets нет, но мы боимся, вдруг чего бы не вышло.
Поэтому по логике, для решения постулируемых  задач
пересборки все затронутые пакеты должны быть незамедлительно
пересобраны и перепроверены.

Что делает сборочница? Она хватает и пересобирает случайную
парочку пакетов из очереди, которым не повезло оказаться в
очереди именно в этот момент. Остальные сотни других пакетов
в Сизифе так и остаются собранными со старой libfoo.

Не абсурд ли это?

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

К примеру, по такой логике такие пакеты, как
янв  4 2005 xlhtml-0.5.1-alt2.src.rpm
десятилетиями каждый день получают новые поводы, чтобы
пересобраться, но почему-то до сих пор не пересобраны.

Чем 2 пакета, собранные за 5 минут до прихода в Сизиф
новой libfoo, хуже, чем 200 пакетов, собранных еще раньше?
Ничем не хуже. Даже лучше с точки зрения необходимости
пересборки, так как собраны на более свежем Сизифе.

Их пересборка -- это логическая ошибка, что-то вроде
известной "ошибки выживших".


-- 

I V

Re: [devel] IХ. Алгоритмы работы сборочницы. O commit. ч.1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

On Sat, Mar 23, 2019 at 12:17:19PM +0200, Igor Vlasenko wrote:
[...]
> Что делает сборочница? Она хватает и пересобирает случайную
> парочку пакетов из очереди, которым не повезло оказаться в
> очереди именно в этот момент. Остальные сотни других пакетов
> в Сизифе так и остаются собранными со старой libfoo.
> 
> Не абсурд ли это?

Это абсурд: сборочница ничего не хватает и ничего случайно не пересобирает.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] IХ. Алгоритмы работы сборочницы. O commit. ч.1

[Alexey Tourbin]

On Sat, Mar 23, 2019 at 1:17 PM Igor Vlasenko <vlasenko@imath.kiev.ua> wrote:
> task merge - это операция, которая получает из репозитория R_n
> и собранного таска B новый репозиторий R_{n+1}.
>
> R_n + B -> R_{n+1}
>
> На этапе task merge в параллельной сборочнице у нас
> возникает проблема, которой в последовательной сборочнице не было.
> Таск B был, вообще говоря, собран не с текущим репозиторием R,
> а с каким-то более старым репозиторием R_k,  k <=n.
> Таск B прошел проверки целостности для R_k,
> но у нас теперь R_n и B может иметь, к примеру, unmets.
>
> Что наша сборочница должна делать на этапе task merge?
> Она должна повторить проверки целостности для B, но
> уже на R_n. Если B проходит проверку, делаем commit
> и получаем новый репозиторий R_{n+1}.
> Иначе возвращаем B в очередь build, на пересборку с R_{n+}.

Ну это большой отход от того, как сейчас сборочная система работает.
Она работает как последовательная серия стадий, последняя стадия -
commit (отсюда и название "task run", проиграть все стадии). При такой
схеме сначала идет сборка пакетов, а потом - генерация нового
репозитория и проверка на unmets. А при вашей схеме получается
шиворот-навыворот: сначала надо сгенерировать репозиторий и проверить
unmets, а потом только собирать пакеты, а потом еще раз сгенерировать
репозиторий и проверить unmets. Не то чтобы это очень серьезный
аргумент против, но это уже как-то по другому мыслится. Также эта
схема более капризна/требовательна к валидности предыдущих результатов
сборки. Сейчас кеширование работает локально, "по месту" (в случае
чего пойдет повторная сборка). В новой схеме надо управлять
суперпозицией состояния "какие сабтаски собрались и прошли все
проверки, чтобы их второй раз не песочить" (напр. если какой-то
сабтаск добавился посередине, то последующие сабтаски надо
сбрасывать). Либо же может быть упрощенный вариант: более или менее
любое изменение в конфигурации сабтасков сбрасывает имеющиеся
результаты сборки у всех сабтасков.

> Что наша сборочница делает, но делать этого не должна,
> против чего я выступаю?
>
> Сборочница просто берет и принудительно пересобирает B на R_n.
> Да, там есть оптимизация - если сборочное окружение пакета
> не изменилось, то его пересборка очевидно избыточна,
> и тогда B коммитится без пересборки, что иногда ускоряет
> сборочницу.
> Однако по сути для не test-only пакетов это та же последовательная
> сборочница. Привязка commit к повторной пересборке
> является в ней узким местом.
>
> И не просто узким в процентах, а узким местом в абсолютных
> величинах, т.е. есть определенный порог, число пакетов,
> которые такая сборочница способна обработать в сутки.
>
> По достижении этого порога сборочница просто захлебнется.
> Но сначала резко увеличится среднее время ожидания
> до попадания пакета в сизиф, пакеты начнут стоять в очередь
> на commit часами, потом сутками,
> появятся AWAITING 1.12, AWAITING 1.18 ...
> начнется грызня, обвинения, что кто-то заливает слишком много пакетов,
> придирки, что пакет залит по недостаточно важной причине,
> рулеж очередью пакетов вручную,
> попытки усложнить майнтайнерам доступ к commit
> (сейчас вот появилась опция --commit, однако ее
> легко заскриптовать; скоро против этого, боюсь, в сборочницу
> и ssh капчу начнут встраивать :)
>
> Если не прекратить это безобразие, и не исправить проблему
> в корне, т.е. не распрямить кривизну в алгоритмах,
> то мы скоро придем к тому, что на доступ к сборочнице
> талоны будут выдавать.

Вы преувеличиваете. Сборочница не захлебнется. Прогресс гарантируется
тем, что один из контендеров всегда коммитится. Остальные уходят на
второй круг. В старых книжках про Unix именно так описан планировщик
процессов: пробуждается несколько процессов, один идет на исполнение,
остальные засыпают до следующего раза. Аналогично pthread_cond_signal
может разбудить несколько тредов (поэтому pthread_cond_wait надо
заворачивать в цикл). В общем, вы жалуетесь на схему, когда ресурс
достается только одному, а остальным - на колу мочало. Но это
распространенная схема.

Теперь поближе к цифрам. Стоимость повторного проигрывания задания на
самом деле состоит из двух частей: константная цена для любого
задания, порядка минуты, плюс переменная цена в зависимости от
количества пакетов, по несколько секунд на пакет. Если в задании много
пакетов, то переменная цена доминирует, и шансы такого задания
закоммититься резко падают (любое другое задание с одним пакетом его
обгонит). Старвейшон это называется по-научному (несправедливое
лишение доступа к ресурсу). Можно попытаться защитить ресурс для
заданий, которые слишком много раз подряд уходят на второй круг.
Например, можно взять эксклюзивный лок на репозиторий. Но если
начинается повторная сборка пакетов, то эксклюзивный лок надо
отпустить! Потому что остальные задания стопорятся на неопределенно
долгое время, а не "несколько секунда на пакет". Справедливость - дело
такое. (Тут часть проблемы чисто техническая - сложно это на шелле
изобразить, взять лок в одном скрипте и отпустить его в другом.)

В общем мне конечно не нравится что большие задания тяжело
закоммитить. Но это не значит, что вся схема негодная. Мне кажется,
что по крайней мере для маленьких заданий пропускной способности
должно хватать. Зачем рекордных показателей добиваться мне не понятно.

> К примеру, по такой логике такие пакеты, как
> янв  4 2005 xlhtml-0.5.1-alt2.src.rpm
> десятилетиями каждый день получают новые поводы, чтобы
> пересобраться, но почему-то до сих пор не пересобраны.
>
> Чем 2 пакета, собранные за 5 минут до прихода в Сизиф
> новой libfoo, хуже, чем 200 пакетов, собранных еще раньше?
> Ничем не хуже. Даже лучше с точки зрения необходимости
> пересборки, так как собраны на более свежем Сизифе.

Вы (в частности) хотите сказать, что вот мы так скрупулезно
отслеживаем влияние пакетов в пределах задания, а когда пакеты все же
попадают в репозиторий, то последующие потенциальное влияние на
пересборку пакетов уже никак не отслеживается. У меня когда-то была
идея сделать "метарепозиторий", в котором как раз бы отслеживались все
промежуточные состояние тестовых пересборок, даже если результат
пересборки отбрасывается. Но что-то до ума я это дело не довел, может
потому что выпивал много. Эх, как там писал Ерофеев, вставай Модест
Петрович, садись дописывать свою божественную оперу Хованщина. А
Модесту Петровичу без выпивки оперу писать вдохновения нету. А как
выпьет, так уж не до оперы.

Все-таки слабое место в вашей схеме -  это суперпозиция валидности при
кешировании. Вы вот пишете, что таск может собираться на каком-либо
старом состоянии репозитория R_k. Если максимально кешировать
результаты сборки, то получится, что таск собирался на состояниях
$R_{k_1},$R{k_2},\ldots$. То есть таск может видеть разные состояние
репозитория. В результате пакеты в таске могут собраться с разными
версиями библиотек!

Re: [devel] IХ. Алгоритмы работы сборочницы. O commit. ч.1

[Igor Vlasenko]

On Sun, Mar 24, 2019 at 03:40:02AM +0300, Alexey Tourbin wrote:
> Ну это большой отход от того, как сейчас сборочная система работает.
> Она работает как последовательная серия стадий, последняя стадия -
> commit (отсюда и название "task run", проиграть все стадии). При такой
> схеме сначала идет сборка пакетов, а потом - генерация нового
> репозитория и проверка на unmets. А при вашей схеме получается
> шиворот-навыворот: сначала надо сгенерировать репозиторий и проверить
> unmets, а потом только собирать пакеты, а потом еще раз сгенерировать
> репозиторий и проверить unmets. 

Здесь, похоже, некоторое недопонимание.
Я не предлагал сначала сгенерировать и проверить unmets,
потом собирать. Ведь предполагается, что
сгенерировать репозиторий и проверить unmets
это уже было сделано во время предыдущего commit.

Я предлагал отвязать выпуск нового репозитория
(commit check+commit) от build+postbuild check+commit check.
Т.е. собираем (build),
выполняем тесты над пакетами (postbuild check),
генерируем временный репозиторий на хардлинках и с ним
делаем commit check (проверить unmets, bad elf symbs и т.д.)
После чего собранный и проверенный task становится в очередь
на commit.

Понятно, что на этапе commit мы опять генерируем временный
репозиторий и с ним опять повотряем commit check.
Где здесь выгода?
1) если build происходил на предыдущем состоянии
репозитория, т. е. как работает последовательная сборочница,
то результаты commit check для нас не устарели
и мы можем просто пропустить commit check, т.е.
потерь производительности в последовательном режиме на
commit check не будет.
2) Для тасков build+postbuild check+commit check
запускается параллельно. Поэтому для человека
время ожидания от постановки в очередь снижается
и существенно, так как ему не нужно ждать, когда
соберутся 20 тасков последовательно, а нужно ждать,
когда соберутся 20 тасков параллельно (что дает
время как 1 самый долгий таск) + время на 21 коммит.

Плюс коммиты тоже можно ускорять параллелизацией,
я об этом писал в ранних письмах.

Итог - наблюдаемое время от заливки до выхода в Сизиф
резко упадет - для человека сборочница станет работать
быстрее, и железо будет задействовано более эффективно,
за счет параллелизации процессов.

> Не то чтобы это очень серьезный
> аргумент против, но это уже как-то по другому мыслится. Также эта
> схема более капризна/требовательна к валидности предыдущих результатов
> сборки. Сейчас кеширование работает локально, "по месту" (в случае
> чего пойдет повторная сборка). В новой схеме надо управлять
> суперпозицией состояния "какие сабтаски собрались и прошли все
> проверки, чтобы их второй раз не песочить" (напр. если какой-то
> сабтаск добавился посередине, то последующие сабтаски надо
> сбрасывать). Либо же может быть упрощенный вариант: более или менее
> любое изменение в конфигурации сабтасков сбрасывает имеющиеся
> результаты сборки у всех сабтасков.

Сейчас сборочница, как понимаю, сбрасывает имеющиеся
результаты сборки у сабтасков, если сборочное окружение изменилось.
Почему бы пока не оставить старое поведение?
Конечно, для сабтасков можно дополнительно пробовать
различные оптимизации, но разговор о них уведет нас
в сторону от главной темы, разрыва связки rebuild+commit.


> Вы преувеличиваете. Сборочница не захлебнется. Прогресс гарантируется
> тем, что один из контендеров всегда коммитится. Остальные уходят на
> второй круг. В старых книжках про Unix именно так описан планировщик
> процессов: пробуждается несколько процессов, один идет на исполнение,
> остальные засыпают до следующего раза. Аналогично pthread_cond_signal
> может разбудить несколько тредов (поэтому pthread_cond_wait надо
> заворачивать в цикл). В общем, вы жалуетесь на схему, когда ресурс
> достается только одному, а остальным - на колу мочало. Но это
> распространенная схема.

Под "сборочница захлебнется" я понимаю ситуацию, как в задаче
про бассейн и две трубы, по одной вода вливается, по другой
выливается, когда входная труба больше, чем выходная -
вода стекать не успеет и бассейн переполнится.
Это аллегория, так как дело даже не в исчерпании каких-либо
физических ресурсов, вроде места на диске, хотя и это может
быть, а в том, что задолго до исчерпания каких либо
ресурсов из-за роста размера очереди пакетов начнет резко расти время
от попадания в очередь до коммита и попадания в репозиторий.

Когда это время исчисляется часами, люди готовы терпеть,
когда сутками - недовольны, когда неделями - хотят революцию.

Кроме того, нужно учесть, что сборочница многоаккаунтовая,
и очередь дополнительно разбита по аккаунтам.
Соответственно, у более активных пользователей проблемы
постоянно (сегодня, к примеру, я еще жду пакет, залитый в
сборочницу полсуток назад, и это для моих пакетов быстро),
у менее активных проблемы начинаются только при авралах,
наподобие идущего сейчас бранчевания.
сборочницы и структура недовольства получается неоднородная,
прямо как в нелинейной civilization:
Сначала 100 довольны. Потом 5 недовольны, 95 довольны.
потом 1 хочет революцию, 9 недовольны, 90 довольны, и т.д.
 
> Теперь поближе к цифрам. Стоимость повторного проигрывания задания на
> самом деле состоит из двух частей: константная цена для любого
> задания, порядка минуты, плюс переменная цена в зависимости от
> количества пакетов, по несколько секунд на пакет. Если в задании много
> пакетов, то переменная цена доминирует, и шансы такого задания
> закоммититься резко падают (любое другое задание с одним пакетом его
> обгонит). Старвейшон это называется по-научному (несправедливое
> лишение доступа к ресурсу). Можно попытаться защитить ресурс для
> заданий, которые слишком много раз подряд уходят на второй круг.
> Например, можно взять эксклюзивный лок на репозиторий. Но если
> начинается повторная сборка пакетов, то эксклюзивный лок надо
> отпустить! Потому что остальные задания стопорятся на неопределенно
> долгое время, а не "несколько секунда на пакет". Справедливость - дело
> такое. (Тут часть проблемы чисто техническая - сложно это на шелле
> изобразить, взять лок в одном скрипте и отпустить его в другом.)
> 
> В общем мне конечно не нравится что большие задания тяжело
> закоммитить. Но это не значит, что вся схема негодная. Мне кажется,
> что по крайней мере для маленьких заданий пропускной способности
> должно хватать. Зачем рекордных показателей добиваться мне не понятно.

Дело не в том, чтобы рекордных показателей добиваться.
Сейчас, если заливать по нескольку пакетов в сутки,
то сборочницей вполне можно пользоваться.
Но там обратная связь - чем больше пользуешься,
тем хуже обслуживание, которое в первую очередь
задевает наиболее активных майнтайнеров.
Поэтому если кто-то из читателей скажет,
что у него все в порядке, это будет как в анекдоте,
когда бабушка говорит внучку, что ей плохо,
а тот в ответ "А я себя чувствую просто великолепно".

Если же заливать большой таск или много маленьких,
то сборочница и вовсе поворачивается задней частью к пользователю.
Ждать заданий неделями приходилось достаточно часто,
чтобы мне это опротивела эта полная ... Старвейшон, как это
называется по-научному?.

Да, не всем это нужно, но мне не отвертеться,
так как на мне от пятой до четверти Сизифа
(по acl трудно сосчитать, так как тот же
perl по факту за мной, но остался со старыми acl).
Чтобы более комфортно работать со сборочницей,
можно попытаться раздать 9/10 своих пакетов в Сизифе,
чтобы свести число поддерживаемых пакетов до среднего.
тогда поддерживающие эти пакеты майнтайнеры
будут заливать их под своими разными аккаунтами,
чтобы плохело всем равномерно.

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

А по поводу рекордных показателей -- они выйдут сами собой.
Современное железо любит параллелизуемые алгоритмы.
Это как заменить в скрипте бекапов 10-летней давности
gzip на pigz и тут же получим рекорд - скрипт отработает
за 20 сек. вместо 5 мин.

> > К примеру, по такой логике такие пакеты, как
> > янв  4 2005 xlhtml-0.5.1-alt2.src.rpm
> > десятилетиями каждый день получают новые поводы, чтобы
> > пересобраться, но почему-то до сих пор не пересобраны.
> >
> > Чем 2 пакета, собранные за 5 минут до прихода в Сизиф
> > новой libfoo, хуже, чем 200 пакетов, собранных еще раньше?
> > Ничем не хуже. Даже лучше с точки зрения необходимости
> > пересборки, так как собраны на более свежем Сизифе.
> 
> Вы (в частности) хотите сказать, что вот мы так скрупулезно
> отслеживаем влияние пакетов в пределах задания, а когда пакеты все же
> попадают в репозиторий, то последующие потенциальное влияние на
> пересборку пакетов уже никак не отслеживается. У меня когда-то была
> идея сделать "метарепозиторий", в котором как раз бы отслеживались все
> промежуточные состояние тестовых пересборок, даже если результат
> пересборки отбрасывается. Но что-то до ума я это дело не довел, может
> потому что выпивал много. Эх, как там писал Ерофеев, вставай Модест
> Петрович, садись дописывать свою божественную оперу Хованщина. А
> Модесту Петровичу без выпивки оперу писать вдохновения нету. А как
> выпьет, так уж не до оперы.

Да, это хотел сказать.
Спасибо, что потратили время прочитать и разобраться.
 
> Все-таки слабое место в вашей схеме -  это суперпозиция валидности при
> кешировании. Вы вот пишете, что таск может собираться на каком-либо
> старом состоянии репозитория R_k. Если максимально кешировать
> результаты сборки, то получится, что таск собирался на состояниях
> $R_{k_1},$R{k_2},\ldots$. То есть таск может видеть разные состояние
> репозитория. В результате пакеты в таске могут собраться с разными
> версиями библиотек!

В "если максимально кешировать" - ключевое слово
"если". Сейчас сборочница не производит такого максимального
кеширования, и я не предлагал его внедрять, но и возражать
не буду, если в будущем кто-то это корректно реализует (с
учетом концепции воспроизводимости сборки, которую выдвинул
Дмитрий, для этого в архиве в собранном taskе нужно будет
хранить информацию, на каком репозитории какой сабтаск был
собран).
Для начала достаточно старой логики, когда результаты
кеширования валидны до тех пор, пока не изменилось сборочное
окружение.

Я в первую очередь предлагаю убрать из commit принудительную
сериализацию уже реализованной параллельной сборки.

Работает эта сериализация параллелизации следующим образом:
отправляем в Сизиф в очередь 20 пакетов в состоянии AVAITING1.
Пока они стоят в очереди на commit, они параллельно
собираются и переходят в состояние AVAITING1.2.
Когда у них доходит очередь до commit, сборочница
отправляет их на пересборку еще раз, не потому,
что пакеты не прошли проверку целостности (unmets,
bad elf symbols, ...) а на всякий случай,
из-за изменения их сборочного окружения.
Это
1) превращает сборочницу в последовательную,
крайне неэффективно использующую железо и искусственно
торможенную.
2) чтобы от пересборки пакетов из-за изменения
их сборочного окружения был какой-то эффект,
ее нужно делать для всех затронутых пакетов,
в том числе пакетов, уже находящихся в Сизифе,
причем лучше делать отдельным фоновым роботом-
пересборщиком, и процесс пересборки оттягивать,
чтобы не раздуть архив Сизиф.

Попытка встраивания этой пересборки в сборочницу
заявленных целей пересборки не достигает,
является логической ошибкой,
которая проявляется как искусственно
созданные тормоза в работе сборочницы.

-- 

I V

Re: [devel] IХ. Алгоритмы работы сборочницы. O commit. ч.1

[Igor Vlasenko]

On Sun, Mar 24, 2019 at 12:50:18AM +0300, Dmitry V. Levin wrote:
> On Sat, Mar 23, 2019 at 12:17:19PM +0200, Igor Vlasenko wrote:
> [...]
> > Что делает сборочница? Она хватает и пересобирает случайную
> > парочку пакетов из очереди, которым не повезло оказаться в
> > очереди именно в этот момент. Остальные сотни других пакетов
> > в Сизифе так и остаются собранными со старой libfoo.
> > 
> > Не абсурд ли это?
> 
> Это абсурд: сборочница ничего не хватает и ничего случайно не пересобирает.

Гм. я, действительно, иногда сдабриваю свои письма
просторечием и эмоциональностью. В научной статье такое было
бы недопустимо. Но ведь это рассылка, я надеялся,
что немного эмоций оживит чтение.
Прошу прощения, если это напрягает.

То же самое могу сказать другими словами.
Во время своей работы сборочница может подвергать
дополнительной пересборке уже собранные пакеты.
[вместо "хватает и пересобирает"]

С одной стороны, такая пересборка может быть
вызвана объективной необходимостью -
непрохождением проверок на целостность
(unmets и т.д.). С другой стороны, большинство
пакетов отправляются на пересборку по критерию,
что их сборочное окружение изменилось.
При чем из всего множества пакетов, которые должны
были быть пересобраны согласно использованному
критерию, пересборке подвергаются только
пакеты, которые были в этот момент в очереди на commit.
Это подмножество не детерминировано
критерием, и формируется случайным образом.

Добавление этой пересборки в логику работы сборочницы
не достигло заявленных целей, но
привело к замедлению сборочницы на порядки
из-за фактической сериализации ее работы.

Другими, более простыми словами,
для попадания пакета в Сизиф, не для test-only,
сборочница фактически собирает пакеты последовательно,
один за одним. Многоядерность помогает изредка,
в основном, на этапе компиляции. Многонодность
не помогает почти совсем, разве разгружает test-only.

При этом очередь перегружена,
а сборочный кластер простаивает.
Такая сборочница тормозит, не масштабируется,
и не эффективно использует железо.

-- 

I V