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 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'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)