[devel] I: weekend mail

[Alexey Tourbin]

On Mon, Sep 07, 2009 at 09:43:17PM +0300, Kirill A. Shutemov wrote:
> 2009/9/7 Alexey Tourbin <at at altlinux.ru>:
> > On Mon, Sep 07, 2009 at 09:04:05PM +0300, Kirill A. Shutemov wrote:
> >> 2009/9/7 Dmitry V. Levin <ldv at altlinux.org>:
> >> > На данный момент мне кажется, что путём распараллеливания выполнения
> >> > заданий можно получить лучший результат, чем путём увеличения $NPROCS.
> >>
> >> Дима, а можно по подробней? Какие работы ведутся в этом направлении?
> >
> > Есть некоторые идеи.  Когда два задания собираются параллельно, то одно
> > из них в конечном счете выбирается жертвой и идёт на второй заход.  Но
> > на втором заходе, скорее всего, пакеты пересобирать не потребуется.
> 
> Есть предварительные оценки при каком максимальном количестве потоков
> сборки результат будет приемлемым?

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

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

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

Нельзя ли улучить гранулярность?  Теоретически можно.  То, что
я описываю, можно считать вырожденным случаем transactional memory:
http://en.wikipedia.org/wiki/Software_transactional_memory
Transactional memory означает, что результат сборки задания зависит
только от конечного числа пакетов, которые мы "читаем" во время сборки.
Поэтому в принципе возможны непересекающиеся транзакции.  Но ведь мы ещё
строим транзитивное замыкание!  Это всё портит -- получается, что каждая
транзакция читает весь репозиторий целиком, потому что она строит
транзитивное замыкание.

Короче, на практике гранулярность улучшить нельзя, потому что тогда надо
отслеживать по каким альтернативным переходам строится транзитивное
замыкание.  То есть нельзя отказаться от принципа что первое успешное
задание вышибает все конкурирующие.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20090907/bb4f19eb/attachment.bin>