Date: Tue, 15 Jun 2021 03:02:03 -0700 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD ports <freebsd-ports@freebsd.org> Subject: Re: Restraining poudriere Message-ID: <73E2FF0F-C814-4F0E-AEA2-DAFB0026C4AA@yahoo.com> In-Reply-To: <3CDFB92D-00A4-42E6-891C-B31F10C4842F@yahoo.com> References: <20210612172957.GA71089@www.zefox.net> <F2BE7E84-8290-443C-8C71-D61095139D14@grem.de> <20210612175704.GC71089@www.zefox.net> <16D4307D-FCAC-4027-A41D-F1BD7265D3FC@yahoo.com> <3CDFB92D-00A4-42E6-891C-B31F10C4842F@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=20
>> On 2021-Jun-12, at 10:57, bob prohaska <fbsd at www.zefox.net> wrote:
>>=20
>>> 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
>>=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.
>>=20
>>=20
>> Based on notes in my poudriere.conf for a 2 GiByte RAM
>> context:
>>=20
>> #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
>>=20
>> So for the smaller RAM context: PARALLEL_JOBS=3D1 is a possibility.
>>=20
>> On a 1 GiByte RPi2B v1.1 (armv7) I've used the combination:
>>=20
>> PARALLEL_JOBS=3D2
>> MAKE_JOBS_NUMBER_LIMIT=3D2
>>=20
>> 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):
>>=20
>> 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
>>=20
>> 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
>>=20
>> 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) . . .
>>=20
>> # By default MAKE_JOBS is disabled to allow only one process per cpu
>> # Use the following to allow it anyway
>> ALLOW_MAKE_JOBS=3Dyes
>>=20
>> So with PARALLEL_JOBS=3D1 that would have a total of 4
>> processes.
>>=20
>> 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.
>>=20
>>=20
>> I also override a bunch of MAX_EXECUTION_TIME_<?>'s and
>> NOHANG_TIME:
>>=20
>> # 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
>>=20
>> # 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
>>=20
>> # 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
>>=20
>> I use:
>>=20
>> USE_TMPFS=3Dno
>>=20
>> in order to avoid tmpfs competing for RAM in these
>> small RAM contexts.
>>=20
>=20
> Something else I will note: you reported for the
> 1 GiBYte RAM RPi3B use:
>=20
> QUOTE
> With OOMA turned off and 6 GB of swap
> END QUOTE
>=20
> Does the system generate a warning about being mistuned
> when the swap space is added:
>=20
> warning: total configured swap (??? pages) exceeds maximum recommended =
amount (??? pages).
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
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.)=20
=
/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/Hexagon/Di=
sassembler/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).
=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?73E2FF0F-C814-4F0E-AEA2-DAFB0026C4AA>