Date: Sat, 12 Jun 2021 17:53:44 -0700 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: Michael Gmelin <freebsd@grem.de>, freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Restraining poudriere Message-ID: <16D4307D-FCAC-4027-A41D-F1BD7265D3FC@yahoo.com> In-Reply-To: <20210612175704.GC71089@www.zefox.net> References: <20210612172957.GA71089@www.zefox.net> <F2BE7E84-8290-443C-8C71-D61095139D14@grem.de> <20210612175704.GC71089@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>>=20
>>=20
>>> On 12. Jun 2021, at 19:31, bob prohaska <fbsd@www.zefox.net> wrote:
>>>=20
>>> ???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.
>>>=20
>>> Can poudriere be configured to tackle packages one at a time?
>>=20
>> Yes, see poudriere.conf:
>>=20
>> # 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=3D1
>>=20
>> -m
>>=20
>=20
> I perhaps misunderstood what was meant by "builders", confusing it
> with threads. Or maybe cores....
>=20
> Trying it now, hoping to see parallel core use.=20
You do not seem to have mentioned use of: vm.pageout_oom_seq=3D
(just vm.pfault_oom_attempts=3D"-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=3D2 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=3Dyes .
PARALLEL_JOBS=3D2
So for the smaller RAM context: PARALLEL_JOBS=3D1 is a possibility.
On a 1 GiByte RPi2B v1.1 (armv7) I've used the combination:
PARALLEL_JOBS=3D2
MAKE_JOBS_NUMBER_LIMIT=3D2
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:
>=20
> MAKE_JOBS_NUMBER_LIMIT is a user variable, so you can either set in
> make.conf or Makefile.local e.g.,
>=20
> $ cat <<\. >>${__MAKE_CONF:-/etc/make.conf}
> .if ${.CURDIR:M*/www/chromium}
> MAKE_JOBS_NUMBER_LIMIT=3D2
> .endif
Setting MAKE_JOBS_NUMBER_LIMIT=3D2 allowed www/chromium to compile =
successfully over
several days. The -DBATCH option was used, in hopes it'd fetch the right =
options.=20
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=3Dyes
So with PARALLEL_JOBS=3D1 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=3D86400
# Cortex-A53 and such are slow for the purpose, allow 4 times the =
defaults:
MAX_EXECUTION_TIME=3D432000
# 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=3D7200
# 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=3D28800
# Cortex-A53 and such are slow for the purpose, allow 4 times the =
defaults:
MAX_EXECUTION_TIME_EXTRACT=3D14400
MAX_EXECUTION_TIME_INSTALL=3D14400
MAX_EXECUTION_TIME_PACKAGE=3D28800
MAX_EXECUTION_TIME_DEINSTALL=3D14400
I use:
USE_TMPFS=3Dno
in order to avoid tmpfs competing for RAM in these
small RAM contexts.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16D4307D-FCAC-4027-A41D-F1BD7265D3FC>