[devel] ресурсоёмкое тестирование пакетов

[Kirill A. Shutemov]

2009/5/15 Alexey Tourbin <at на altlinux.ru>:
> On Fri, May 15, 2009 at 11:05:35PM +0300, Kirill A. Shutemov wrote:
>> 2009/5/15 Alexey Tourbin <at на altlinux.ru>:
>> >> И почему бы не включить сборку в
>> >> несколько потоков ?
>> >
>> > Потому что такова семантика сборки заданий: они обладают семантикой
>> > транзакции.  Если задание собрано успешно, то оно переводит репозитарий
>> > в новое состояние, и сборка следующего задания начинается уже на новом
>> > репозитарии.  Нельзя начинать собирать несколько заданий на старом
>> > репозитарии и потом "сводить" несколько результатов сборки в один новый
>> > репозитарий.  Это может закончиться очень плохо.
>>
>> Алексей, существует ли относительно недорогой способ выяснить влияют ли
>> задания друг на друга после, собственно, сборки?
>
> Нет такого способа, конечно же.
>
> Грубо говоря, у нас есть
> task1=(1/.git 2/.git) и
> task2=(1/.git 2/.git).
>
> Выяснить, влияют ли эти два задания друга на друга, -- значит научиться
> предсказывать будущее.  То есть предсказывать результат сборки.

Я ж написал "после".

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

Насколько сложно реализовать этот алгоритм и есть ли он в TODO?

>> На ARM есть возможность сделать сборочную ферму из большого количества
>> недорогого железа. Но вот без параллелизма всё грустно.
>
> Сумма неликвидного желаза не равна единице ликвидного железа: сумма хуже.

Это понятно :(

В случае ARM, самое производительное, из того, что есть в свободном доступе --
SheevaPlug: 1.2GHz, 512Mb RAM. Я себе купил две штуки. Буду пробовать собирать.

Кстати, а от много ядерного железа при текущей архитектуре прок есть?