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

[Alexey Tourbin <at@altlinux.ru>]

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

On Fri, May 15, 2009 at 11:36:14PM +0300, Kirill A. Shutemov wrote:
> >> Алексей, существует ли относительно недорогой способ выяснить влияют ли
> >> задания друг на друга после, собственно, сборки?
> >
> > Нет такого способа, конечно же.
> >
> > Грубо говоря, у нас есть
> > task1=(1/.git 2/.git) и
> > task2=(1/.git 2/.git).
> >
> > Выяснить, влияют ли эти два задания друга на друга, -- значит научиться
> > предсказывать будущее.  То есть предсказывать результат сборки.
> 
> Я ж написал "после".

А.  А что тогда такое "влияет"?  Единственный рациональный ответ -- что
пакеты из одного задания попадают в сборочный чрут при сборке пакетов
другого задания.  Но что такое "пакеты из задания" "попадают"?  Это
жаргон для маскировки сути дела.  А суть дела в том, что надо
сформировать новый репозитарий с пакетами из первого задания и начать
собирать второе задание.  Это в принципе возвращает нас к сериализации
заданий, как оно сейчас реализовано.

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

Это отчасти реализовано.  Когда часть пакетов собралось, а часть не
собралось, то при возобновлении задания для первой части будет
диагностика "no need to rebuild".  См. girar-builder/remote/gb-remote-build.
Но это не реализовано в виде, пригодном для спекулятивной сборки.

Для спекулятивной сборки нужно несколько нодов.  И нужно перделывать
task/seq потому что не ясно в каком же статусе эта спекулятивная сборка
будет идти.  И как поддерживать очередь этих спекулятивных сборок с ходу
трудно сказать.  В общем, идея гниловатая. :)

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

Насколько быстро эта штука будет openoffice собирать?  Я боюсь что на
таких нативных корытах мы никуда не уедем.  В плане придания арму
статуса более поддерживаемой архитектуры.

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

Нет.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]