Date: Mon, 20 Sep 2021 17:47:03 -0700 From: Mark Millard via freebsd-ports <freebsd-ports@freebsd.org> To: =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= <rollingbits@gmail.com>, 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: <5FC47541-1F8E-4F51-8D98-6AA7AD538D51@yahoo.com> In-Reply-To: <6A5450DA-A50A-4A9F-AC9B-430016F92D50@yahoo.com> References: <64B80EEA-DECC-4286-AC80-5BE55B7F19D4@yahoo.com> <7EC14B75-654D-45BA-8260-B3D922B81603@gmail.com> <A3FFD4A1-78FE-41B2-BC4C-D0F733AC878D@yahoo.com> <6A5450DA-A50A-4A9F-AC9B-430016F92D50@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Sep-20, at 15:10, Mark Millard <marklmi at yahoo.com> wrote: > On 2021-Sep-20, at 13:58, Mark Millard <marklmi at yahoo.com> wrote: >=20 >>=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 >=20 >=20 > Sorry: a stray click lead to an accidental send of a reply with > no additional content. >=20 >=20 > 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. >=20 >=20 > 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 discovered that the aarch64 targeting bulk -a would not sucessfully build something I wanted in the bulk -a activity. So I stopped that build and will restart at some point after updating /usr/ports/ to a version that should build that port.] Well, my attempt to build llvm12 with debug info, when targeting armv7, did not go well. The intent was so that a backtrace of its linker would be useful to me. So this type of experiment proved not useful. > 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?5FC47541-1F8E-4F51-8D98-6AA7AD538D51>