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

On 2022-Jan-27, at 14:21, Mark Millard <marklmi@yahoo.com> wrote:

> 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.

I just started a poudriere bulk devel/llvm13 build
in a UFS context:
. . .
[00:00:49] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP -PYCLANG
[00:00:49] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP +PYCLANG
. . .
[00:02:13] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3

>>> 
>>> (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.)



For reference (lines split for readability):

# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #37
main-n252475-e76c0108990b-dirty: Sat Jan 15 21:53:08 PST 2022
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400047 1400047

# uname -apKU
FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #37
main-n252475-e76c0108990b-dirty: Sat Jan 15 21:53:08 PST 2022
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400047 1400047


===
Mark Millard
marklmi at yahoo.com