Date: Mon, 20 Sep 2021 15:10:08 -0700 From: Mark Millard via freebsd-ports <freebsd-ports@freebsd.org> To: =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= <rollingbits@gmail.com> Cc: freebsd-ports@freebsd.org Subject: Re: armv7 target (on aarch64 HW) and poudriere-based emulators/mame link failure vs. success based on the number of cores Message-ID: <6A5450DA-A50A-4A9F-AC9B-430016F92D50@yahoo.com> In-Reply-To: <A3FFD4A1-78FE-41B2-BC4C-D0F733AC878D@yahoo.com> References: <64B80EEA-DECC-4286-AC80-5BE55B7F19D4@yahoo.com> <7EC14B75-654D-45BA-8260-B3D922B81603@gmail.com> <A3FFD4A1-78FE-41B2-BC4C-D0F733AC878D@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Sep-20, at 13:58, Mark Millard <marklmi at yahoo.com> wrote: >=20 > On 2021-Sep-20, at 12:54, Lucas Nali de Magalh=C3=A3es = <rollingbits@gmail.com> wrote: >=20 >> On Sep 19, 2021, at 6:14 AM, Mark Millard via freebsd-toolchain = <freebsd-toolchain@freebsd.org> wrote:(=E2=80=A6) >>=20 >> (=E2=80=A6) >>=20 >> The HoneyComb failure looks to me like like hitting the process >> size limitations for armv7, something that did not happen on the >> MACCHIATObin Double Shot or RPi4B (fewer cores). >>=20 >> It looks to me like 32-bit architectures (such as armv7) should >> possibly have the multi-threaded link disabled by default >> for FreeBSD unless ports are adjusted to disable multi-threaded >> individually. >>=20 >> (=E2=80=A6) >=20 > There are a few a few problems with your analysis: 32 and 64 bit > architectures sizes aren't that small and much of all OSes today > evolved around extending these sizes. This doesn't means that one > can not use all of it but that the analysis requires a little more = "salt". > So it looks like you used all of something=E2=80=A6 maybe you need to = adjust > some numbers somewhere. >=20 > Then, processes and threads existed far before the existence of > multicore desktop CPUs. Running with more threads/processes than > the number of cores you have only means that some swapping *may be* > necessary. If you have enough RAM, swap isn't really necessary. So I = think > this makes your suggestion ridiculous. >=20 Sorry: a stray click lead to an accidental send of a reply with no additional content. The above did not indicate any specific errors for me to fix, experiments to try, or even any specific alternate hypothesis for the inability to allocate in the failing context that I described. So I've no clue of a good way to make any progress from what is written. I see no reason to withdraw the suggestion based on the above. I'm well aware that there are tradeoffs and that the suggestion might not be used even if I've gotten everything correct about the failure's cause. After the HoneyComb system is done with the bulk -a activity targeting aarch64, I'l likely try bulk -w targeting armv7 in hopes of getting a .core for the failure. That will be days away and the rebuild attempt for emulators/mame will have to rebuild the prerequisite ports (the armv7 packages were deleted before starting the aarch64 targeting builk -a). So even more time. I'd consider other evidence gathering alternatives that might better indicate specifically why the allocation fails in the failing context. But the large nubmer of build steps prior to the failing link and such probably limit the options. =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?6A5450DA-A50A-4A9F-AC9B-430016F92D50>