Re: armv7 target (on aarch64 HW) and poudriere-based emulators/mame link failure vs. success based on the number of cores

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:
> 
>> 
>> On 2021-Sep-20, at 12:54, Lucas Nali de Magalhães <rollingbits@gmail.com> wrote:
>> 
>>> On Sep 19, 2021, at 6:14 AM, Mark Millard via freebsd-toolchain <freebsd-toolchain@freebsd.org> wrote:(…)
>>> 
>>> (…)
>>> 
>>> 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).
>>> 
>>> 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.
>>> 
>>> (…)
>> 
>> 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… maybe you need to adjust
>> some numbers somewhere.
>> 
>> 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.
>> 
> 
> 
> 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 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.




===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)