Re: poudriere and MAX_EXECUTION_TIME_PACKAGE vs. NOHANG_TIME

On 2022-Jan-24, at 23:14, Mark Millard <marklmi@yahoo.com> wrote:

> [Just a resend with a corrected email address.]
> 
> On 2022-Jan-24, at 22:05, Mark Millard <marklmi@yahoo.com> wrote:
> 
> I've been experimenting with WITH_DEBUG= port builds via
> poudriere-devel --including some testing of bulk -a .
> 
> For something like devel/llvm13 the .pkg file generated is
> huge (multi-GiBytes) and takes more time to produce than
> the rest of the llvm13 build did. This is with that being
> the only active builder (no otherwise significant activity
> on the ThreadRipper 1950X in use for the experiments).
> 
> If other builders or other activity leads to load averages
> noticeably above the hardware thread count (32 in the
> context), that adds to how long teh .pkg file generation
> takes.
> 
> What I noticed was that setting MAX_EXECUTION_TIME_PACKAGE
> effectively did no good for the load average case if
> the NOHANG_TIME was shorter: it stops for the NOHANG_TIME
> during the .pkg generation instead.
> 
> In part this is the lack of having any output (progress
> messaging?) while the .pkg file is being generated, although
> may be one could argue that the package phase possibly
> should not have NOHANG_TIME applied at all.
> 
> I'm only noting the relationship and need to understand
> it when setting the figures --and the need for large
> figures if WITH_DEBUG= is to be in use for various ports.
> 
> I've not checked if there is any other phases/activities
> that might have similar issues possible. I just actually
> ran into having devel/llvm* builders stop for NOHANG_TIME .

My context for this ended up being somewhat messier:
2 ports really did hang up and, having set the
NOHANG_TIME to the very large values for devel/llvm*'s
(and the like), the hung up builders would take a very
long time to fail, despite hanging up early.

After the increase of NOHANG_TIME, I was not using
very many builders for other reasons (disk space vs.
devel/llvm* disk use during builds). Blocking the
builders was not a good thing.

I hope that, at some point, having a smaller NOHANG_TIME
and a larger MAX_EXECUTION_TIME_PACKAGE will allow
package to run based on the MAX_EXECUTION_TIME_PACKAGE
value, not the NOHANG_TIME value.

I'm not picky between:

A) pkg outputting to the log once and a while
vs.
B) NOHANG_TIME just not applying to the pkg run.


FYI: I worked around the hung builders by killing
processes that were supposed to be doing the build
activity. This avoided stopping long-running builds
that were making progress and lead to freeing the
builders for other work --instead of waiting for
NOHANG_TIME.

===
Mark Millard
marklmi at yahoo.com