Re: Restraining poudriere

From: Mark Millard via freebsd-arm <>
Date: Sun, 13 Jun 2021 00:53:44 UTC
On 2021-Jun-12, at 10:57, bob prohaska <fbsd at> wrote:

> On Sat, Jun 12, 2021 at 07:36:48PM +0200, Michael Gmelin wrote:
>>> On 12. Jun 2021, at 19:31, bob prohaska <> 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
>> -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

#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 .

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:


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):

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}
> .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. 

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

So with PARALLEL_JOBS=1 that would have a total of 4

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

# 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
# Cortex-A53 and such are slow for the purpose, allow 4 times the defaults:

# 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
# 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.

# Cortex-A53 and such are slow for the purpose, allow 4 times the defaults:

I use:


in order to avoid tmpfs competing for RAM in these
small RAM contexts.

Mark Millard
marklmi at
( went
away in early 2018-Mar)