Re: why does devel/electron41 show as blacklisted on pkg.f.o

On 6/30/26 01:22, Dag-Erling Smørgrav wrote:
> Mark Felder <[email protected]> writes:
>> Yes, it will often be competing with multiple llvm, gcc, and the rust
>> port. But it has never taken anywhere near as long as it does on the
>> build cluster.
> 
> Poudriere's scheduling is lousy (though it's mostly not its own fault).
> You basically have a choice between occasional gridlock and chronic
> underutilization, and it's actually easier to gridlock a beefier builder
> than a skinnier one.  I desperately want to do something about it, but
> it's more work than I can take on in my spare time, so it's not going to
> happen any time soon unless someone is willing to sponsor it.
> 
> DES

Given the context that exists, for poudriere-devel bulk runs that build
the 34000+ port-packages, the best overall time minimization without
having memory or disk resource failures that I've had has been based on:


) Generally high load averages so that there is mostly pending useful
work ready to be worked on instead of even more time spent idle waiting
for useful work to do.

) A fair sized amount of RAM for the number of hardware threads.
  [Example: 192 GiBytes of RAM for 32 hardware threads on the least time
taking system.]

) Lots of SWAP space that is PCIe Optane speed or the like.
  [In general I avoid spinning rust.]

) So, as an example: RAM+SWAP = 4.6*RAM, though I have access to an
example that is closer to only 3.6*RAM --the earlier mentioned system.

) Avoiding builders that would have large tmpfs usage for unconstrained
USE_TMPFS=all from using much tmpfs. This is avoidance of resource
failures. Such failures lead to a lot more overall time from the retries.

) Also some mutual exclusions for what runs at the same time. More
avoidance of resource failures.

) Biasing that long running mostly-single threading builds have a higher
tendency to run in parallel with other building port-packages, instead
of by themselves.

) Allowing slower processing hardware threads to still contribute to
progress, rather than being idle.


But the details would not scale well to hundreds or more of hardware
threads: scaling RAM+SWAP would not be practical. For my context it
would not even be practical to double the number of hardware threads.

It also makes looking at individual port-package build times not
particularly useful. [The minimum overall time < the sum of the
individual minimum times.]

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