Re: Restraining poudriere

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.

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