Re: Restraining poudriere

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.


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