Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current

On 2022-Jan-27, at 13:48, bob prohaska <fbsd@www.zefox.net> wrote:

> On Thu, Jan 27, 2022 at 12:12:20PM -0800, Mark Millard wrote:
>> 
>> 
>> On 2022-Jan-27, at 11:31, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>>> On 2022-Jan-27, at 08:45, bob prohaska <fbsd@www.zefox.net> wrote:
>>> 
>>>> Attempts to compile devel/llvm13 on a Pi4 running -current (updated
>>>> on 20220126) with 8 GB of RAM and 8 GB of swap has failed on two occasions using 
>>>> make -DBATCH > make.log & 
>>>> in /usr/ports/devel/llvm13 using the system compiler. The system is
>>>> self-hosted. 
>> 
>> Context question: ZFS? UFS?
> 
> UFS

Okay. I just started a poudriere bulk devel/llvm13 build
in a ZFS context:

. . .
[00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP -PYCLANG
[00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP +PYCLANG
. . .
[00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3

I have my patched top monitoring and reporting various
"Maximum Observed ???" (MaxObs???) figures.

May be I can get a 8GiByte RPi4B UFS context updated and
going as well.

>> 
>> (In things involving memory usage issues, knowing which is
>> always appropriate because of differences in memory use
>> patterns.)
>> 
>>> 
>>> Your context proves the metadata problem really happens, so
>>> the messaging should be fixed to not be misleading.
>>> 
> 
> I looked for and didn't find any "too much swap"
> warnings in the boot output, as expected with
> RAM=SWAP.

Good to know that nothing was odd about the boot's
swapon activity.

>>> But it looks like you have identified a test context
>>> for the "swap blk uma zone" and "swap pctrie uma zone"
>>> handling.
> 
> I was hoping to reproduce the first failure, with clang 
> exiting on error 139. Just for curiosity's sake I restarted 
> the build of devel/llvm13 without cleaning. Looks like the
> result won't be known until morning. 

Note: I dropped Mark Johnston from the TO/CC --at least until
we have technical information about the vm subsystem's
behavior that might be interesting, such as which metadata
caused the messaging. (The context being uFS may have been of
interest, for example, but nothing in my reply does him any
good.)

===
Mark Millard
marklmi at yahoo.com