[devel] ресурсоёмкое тестирование пакетов
Alexey Tourbin
at на altlinux.ru
Сб Май 16 01:07:11 MSD 2009
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 собирать? Я боюсь что на
таких нативных корытах мы никуда не уедем. В плане придания арму
статуса более поддерживаемой архитектуры.
> Кстати, а от много ядерного железа при текущей архитектуре прок есть?
Нет.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : отсутствует
Тип : application/pgp-signature
Размер : 197 байтов
Описание: отсутствует
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20090516/64fe4ec9/attachment.bin>
Подробная информация о списке рассылки Devel