Re: Restraining poudriere

On 2021-Jun-12, at 18:35, Mark Millard <marklmi at yahoo.com> wrote:

> On 2021-Jun-12, at 17:53, Mark Millard <marklmi at yahoo.com> wrote:
> 
>> On 2021-Jun-12, at 10:57, bob prohaska <fbsd at www.zefox.net> wrote:
>> 
>>> On Sat, Jun 12, 2021 at 07:36:48PM +0200, Michael Gmelin wrote:
>>>> 
>>>> 
>>>>> On 12. Jun 2021, at 19:31, bob prohaska <fbsd@www.zefox.net> wrote:
>>>>> 
>>>>> ???In playing with poudriere on raspberry pi 3 and 4 it seems to
>>>>> work well on the 8 GB Pi4 but is over-optimistic on the 1 GB Pi3.
>>>>> 
>>>>> Can poudriere be configured to tackle packages one at a time?
>>>> 
>>>> Yes, see poudriere.conf:
>>>> 
>>>> # parallel build support.
>>>> #
>>>> # By default poudriere uses hw.ncpu to determine the number of builders.
>>>> # You can override this default by changing PARALLEL_JOBS here, or
>>>> # by specifying the -J flag to bulk/testport.
>>>> #
>>>> # Example to define PARALLEL_JOBS to one single job
>>>> # PARALLEL_JOBS=1
>>>> 
>>>> -m
>>>> 
>>> 
>>> I perhaps misunderstood what was meant by "builders", confusing it
>>> with threads. Or maybe cores....
>>> 
>>> Trying it now, hoping to see parallel core use. 
>> 
>> You do not seem to have mentioned use of: vm.pageout_oom_seq=
>> (just vm.pfault_oom_attempts="-1"). You also mention "[with]
>> OOMA turned off" but no combination of settings actually
>> completely disables the possibility.
>> 
>> 
>> Based on notes in my poudriere.conf for a 2 GiByte RAM
>> context:
>> 
>> #NOTE: on 2 GiByte RAM contexts I've used: PARALLEL_JOBS=2 but
>> #      two llvm*'s are likely the biggest combination that
>> #      could occur in my context. lang/rust or other even
>> #      larger build contexts need not be appropriate.  I
>> #      normally use ALLOW_MAKE_JOBS=yes .
>> PARALLEL_JOBS=2
>> 
>> So for the smaller RAM context: PARALLEL_JOBS=1 is a possibility.
>> 
>> On a 1 GiByte RPi2B v1.1 (armv7) I've used the combination:
>> 
>> PARALLEL_JOBS=2
>> MAKE_JOBS_NUMBER_LIMIT=2
>> 
>> so that no more than 4 generally active processes in
>> builders/JOBS overall. You have used MAKE_JOBS_NUMBER_LIMIT
>> before to build www/chromium (2018-Dec-18 report):
>> 
>> QUOTE
>> On Fri, Dec 14, 2018 at 05:59:21AM +0100, Jan Beich wrote:
>>> 
>>> MAKE_JOBS_NUMBER_LIMIT is a user variable, so you can either set in
>>> make.conf or Makefile.local e.g.,
>>> 
>>> $ cat <<\. >>${__MAKE_CONF:-/etc/make.conf}
>>> .if ${.CURDIR:M*/www/chromium}
>>> MAKE_JOBS_NUMBER_LIMIT=2
>>> .endif
>> 
>> Setting MAKE_JOBS_NUMBER_LIMIT=2 allowed www/chromium to compile successfully over
>> several days. The -DBATCH option was used, in hopes it'd fetch the right options. 
>> END QUOTE
>> 
>> As for allowing 4 processes in a build per builder
>> (a.k.a. per JOB) generally (for the 4 core context
>> without MAKE_JOBS_NUMBER_LIMIT in use) . . .
>> 
>> # By default MAKE_JOBS is disabled to allow only one process per cpu
>> # Use the following to allow it anyway
>> ALLOW_MAKE_JOBS=yes
>> 
>> So with PARALLEL_JOBS=1 that would have a total of 4
>> processes.
>> 
>> I'll note that threads is yet a separate issue. For example the
>> llvm linker might use 1 or 2 more threads than there are cores.
>> (These happen in one process.) poudriere does not have a control
>> over such tread usage by programs. Threads may or may not use
>> up significant RAM in total.
>> 
>> 
>> I also override a bunch of MAX_EXECUTION_TIME_<?>'s and
>> NOHANG_TIME:
>> 
>> # This defines the max time (in seconds) that a command may run for a build
>> # before it is killed for taking too long. Default: 86400
>> #MAX_EXECUTION_TIME=86400
>> # Cortex-A53 and such are slow for the purpose, allow 4 times the defaults:
>> MAX_EXECUTION_TIME=432000
>> 
>> # This defines the time (in seconds) before a command is considered to
>> # be in a runaway state for having no output on stdout. Default: 7200
>> #NOHANG_TIME=7200
>> # Cortex-A53 and such are slow for the purpose, allow 4 times the defaults:
>> # Also: boost-libs seems to have a long time with no output but it making
>> # progress in parallel builds.
>> NOHANG_TIME=28800
>> 
>> # Cortex-A53 and such are slow for the purpose, allow 4 times the defaults:
>> MAX_EXECUTION_TIME_EXTRACT=14400
>> MAX_EXECUTION_TIME_INSTALL=14400
>> MAX_EXECUTION_TIME_PACKAGE=28800
>> MAX_EXECUTION_TIME_DEINSTALL=14400
>> 
>> I use:
>> 
>> USE_TMPFS=no
>> 
>> in order to avoid tmpfs competing for RAM in these
>> small RAM contexts.
>> 
> 
> Something else I will note: you reported for the
> 1 GiBYte RAM RPi3B use:
> 
> QUOTE
> With OOMA turned off and 6 GB of swap
> END QUOTE
> 
> Does the system generate a warning about being mistuned
> when the swap space is added:
> 
> warning: total configured swap (??? pages) exceeds maximum recommended amount (??? pages).
> 
> Such likely would contribute to "swap blk zone exhausted"
> notices. I avoid setting up contexts that generate this
> warning about the configured swap by avoiding having too
> much swap space for the RAM available to manage it.
> 
> As covered in multiple past exchanges, attempting to adjust
> kern.maxswzone to deal with this has other tradeoffs (less
> space for other kernel information) if I understand right.
> It takes more knowledge than I have to know if such tradeoffs
> are appropriate for a particular context.
> 
> My memory is that when I move the Rock64 media to an RPi3B
> for an experiment, I use a 3 GiByte swap space to avoid the
> warning. (I have a 2nd swap partition that can be also put
> to use on the 4 GiByte RAM Rock 64 that goes unused on
> the RPi3B. It is rare that I do things sort of experiments.
> 

I took a look via https://pkg-status.freebsd.org and the FreeBSD
servers have been building aarch64 llvm10-10.0.1_5 since mid-Feb.
without such failures. (Previously llvm10-10.0.1_4 was building.) 

/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/Hexagon/Disassembler/HexagonDisassembler.cpp

is used. It makes me wonder if you have a cached distfile
that is corrupted or some such. (The servers use poudriere
to do the builds and they do not disable targets.)

I do not know if the logfile would give a hint about that or not.

I do not remember your indicating what /usr/ports commit
poudriere is using --or which way you have poudriere configured
to get a ports tree to work with (or related configuration
information).


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)