On 5/25/26 22:29, Kurt Jaeger wrote:
> Hi!
> 
>>>> I mean, others which aren't electron based which also
>>>> take huge resources to build.
>>>
>>> Yes. It's complicated.
>>
>> Could compute be distributed?

To what performant machines that are not already building for other
combinations of platform/archtecture (amd64, i386, aarch64, as stands),
quarterly/latest, and FreeBSD OS version?

amd64/i386:
143amd64-default and -quarterly (beefy22 and beefy 20)
150amd64-default and -quarterly (beefy23 and beefy 21)
main-amd64-default              (beefy24)
143i386-default and -quarterly  (beefy18 and beefy 19)

That is 7 combinations, with 7 machines.

aarch64:
143arm64-default and -quarterly (ampere3 and ampere4)
150arm64-default and -quarterly (ampere5 and ampere4)
main-arm64-default              (ampere2)

That is 5 combinations and 4 machines. (ampere3 and ampere2 are vastly
slower builder machines.)

(arm7 is no longer built and so no longer competes for use of the
ampere* machines.)

(Security is a big constraint on remote distribution to machines not
under direct control.)

>>
>> Desktop essentials have grown huge :(

yep.

> 
> The ports tree is a dependency tree. To target the fastest way for
> upgrades would require to rebuild if a dependency changes
> and to optimise the longest path, compile-time-wise.
> 
> Finding that longest path would be interesting.
> 
> Some elements in that path might have problems with parallel
> compilation (MAKE_JOBS_UNSAFE option). Fixing those elements
> might help.
> 
> Because this longest path is not subject to parallelization, I'm
> not sure it's easily achievable.
> 
> It is subject to CPU takt rate optimization, therefore using faster
> CPUs might help as well. And large TMPFS.
> 

TMPFS: competes for RAM+SWAP

So: there needs to be enough RAM+SWAP to handle the other RAM+SWAP usage
and also all the tmpfs use by each builder. (Of course, the more of this
that is RAM instead of SWAP, the better for time taken to do builds.)

Also: As stands poudriere(-devel) does not release all the tmpfs use by
a builder when one of its builds finishes: it waits until the builder
starts its next build (if any) to delete much of it for the large cases.
I builder can hold 30 GiBytes+ of tmpfs RAM+SWAP after a lang/*rust*
build, for example.

-- 
===
Mark Millard
marklmi at yahoo.com

Reply via email to