Date: Tue, 14 Sep 2021 11:22:01 -0700 From: Mark Millard via freebsd-ports <freebsd-ports@freebsd.org> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: freebsd-ports@freebsd.org Subject: Re: FYI: An odd poudriere-devel problem during a bulk -a (on aarch64 (ZFS) targeting armv7) Message-ID: <5ADB2A14-A6D2-4CE6-B7AC-77AE5592DD08@yahoo.com> In-Reply-To: <f6b86204-4cba-be4d-cd5d-24e9478d6897@FreeBSD.org> References: <76EABFD4-9286-4A18-9382-CEAC9E06F9FD.ref@yahoo.com> <76EABFD4-9286-4A18-9382-CEAC9E06F9FD@yahoo.com> <f6b86204-4cba-be4d-cd5d-24e9478d6897@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Sep-14, at 09:12, Bryan Drewery <bdrewery@FreeBSD.org> wrote:
> On 9/13/2021 3:57 PM, Mark Millard wrote:
>> [31:27:49] [14] [00:00:00] Building devel/erlang-cf | erlang-cf-0.3.1
>> [31:27:49] [14] [31:27:49] Finished devel/erlang-cf | =
erlang-cf-0.3.1: Failed: starting
>> [31:27:50] [14] [31:27:50] Skipping devel/erlang-erlware_commons | =
erlang-erlware_commons-1.1.0: Dependent port devel/erlang-cf | =
erlang-cf-0.3.1 starting
>=20
> This looks like something poudriere-devel-3.3.99.20210907 should have =
fixed.
But:
# poudriere version
poudriere-git-3.3.99.20210907_1
I'll note that the HoneyComb context has 16 Cortex-A72's
and 64 GiBytes of RAM and I used 16 builders with
ALLOW_MAKE_JOBS=3Dyes . I use a modfied version of top that
records and reports various MaxObs??? ("Maximum Observed")
figures and I had it reporting on running threads, not
processes. The figures were:
load averages: . . . MaxObs: 108.17, 93.28, 83.20
. . . threads: . . . 185 MaxObsRunning
Mem: . . . 25584Mi MaxObsActive, 56694Mi MaxObsWired, 59362Mi =
MaxObs(Act+Wir+Lndry)
Swap: 122880Mi Total, 122880Mi Free, 25994Mi =
MaxObs(Act+Lndry+SwapUsed), 59362Mi MaxObs(Act+Wir+Lndry+SwapUsed)
(It reported some Laundry use but no Swap use.)
So I pushed it harder in various respects than may be
typical relative to competing threads. (ZFS context.)
The build completed in somewhat under 87.25 hours,
building 26995 ports successfully.
I do have various poudriere timeouts set larger than
normal, in part due to using nearly identical .conf
files on a variety of 4-core aarch64 and an armv7 as
well.
Unfortunately, I do not have access to PowerPC any more to
see if it its weak memory model type of context also shows
such issues. (And I've never had access to such with more
than 4 FreeBSD "cpus": just old PowerMacs back then.)
My only non-aarch64/non-armv7 FreeBSD context that I have
acess to is amd64 (a ThreadRipper 1950X with 128 GiByte of
RAM).
I'll note that I've never done a bulk -a on aarch64 or armv7
before. So I've no prior matching context to compare against.
This was on aarch64 but armv7 being targeted:
# poudriere jail -i -jmain-CA7
Jail name: main-CA7
Jail version: 14.0-CURRENT
Jail arch: arm.armv7
Jail method: null
Jail mount: /usr/obj/DESTDIRs/main-CA7-poud
Jail fs: =20
Jail updated: 2021-06-27 17:58:33
Jail pkgbase: disabled
At some point I'll likely try targeting aarch64 for a
bulk -a run instead.
I'll note that the kernel and aarch64 world invovled were
built using -mcpu=3Dcortex-a72 and the armv7 world was built
with -mcpu-cortex-a7 ..
Another oddity:
I'll note that I had some ^T's that I'd typed that did not work
(no output or only the kernel backtrace) and after the bulk -a
finished (just recently) there was:
[87:11:35] Unmounting file systems
# ^T^T^T^T
-su: : not found
# ^T^T^T^T^T^T^T^T^T^T^T^T^T
So: The ^T's that did nothing made it into the input buffer
and showed up later.
=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?5ADB2A14-A6D2-4CE6-B7AC-77AE5592DD08>