RPI3 swap experiments [a failure for a Pine64+ 2GB at head -r337400 without vm.pageout_oom_seq or #define adjustment, no I/O latency problem reported]

[Mark Millard]

Based on having all Mark Johnston's reporting-patches but
not adjusting vm.pageout_oom_seq or the #define I got
an OOM kill during buildworld on a Pine64+ 2GB (so 2 GiByte
of RAM).

I'll give other environment characteristic later.
But that no I/O latency problems were reported by the
patches is not a surprise: the device with the root file
system and swap partition has not historically shown
latency problems and is not of a type usually used with
such a system (better than normal).

I expect that this case shows that the problem does not
require I/O latency problems to be involved.

The only console message was:

Aug 12 09:30:13 pine64 kernel: v_free_count: 7773, v_inactive_count: 1
Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out of swap space

The build had been started at: 01:44:59 so the failure
was around 7 hours 45 minutes into the build.

The build log shows:

Building /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/libclang/Sema/SemaDeclAttr.o
Building /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/libclang/Sema/SemaDeclCXX.o
Building /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/libclang/Sema/SemaDeclObjC.o
--- Sema/SemaDecl.o ---
c++: error: unable to execute command: Killed
c++: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
Target: aarch64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
c++: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/SemaDecl-44b104.cpp
c++: note: diagnostic msg: /tmp/SemaDecl-44b104.sh
c++: note: diagnostic msg: 

********************
*** [Sema/SemaDecl.o] Error code 254


Description of the context . . .

I have access to a Pine64+ 2GB (that was updated to -r337400
via a cross build) and had it doing a self-hosted rebuild of
-r337400 via -j4. (This was a jump from its last update over
10 months ago. I've not historically had OOM kill problems.)

The root file system is on a USB3.0-capable 240 GB SSD
plugged in the lower slot, where it gets the 480Mbps
USB 2.0 classification. The kernel was loaded from a
microSDHC card that also supplied a /etc/fstab that
redirects to the USB root file system.

(With an edit of that /etc/fstab the microSDHC can boot
standalone: I keep it tracking.)

# usbconfig
ugen0.1: <Allwinner EHCI root HUB> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.1: <Generic OHCI root HUB> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen0.2: <OWC Envoy Pro mini> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (0mA)

Historically I've not observed latency problems for
the USB SSD. None were reported by Mark Johnston's
reporting patches, unlike for Bob P.'s context.

In top I'd seem over 1400 Mem Active, well over the amount
of RAM in a rpi3 or rpi2. (Of course with more memory the
relative timings of what is running will be different
from what rpi3's/rpi2's get. That is not the only source of
variation.)

Swap had been used, I've seen 19M Used shown (of 3 GiByte
in the swap partition in use). (I do not have in place my
prior changes to record and report the maximum observed
swap used: I reverted to the normal version of top during
top's development activity.)

I'm unlikely to have observed approximate the maximums for
Mem Active or Swap Used. These are things I wish there were
normally available for inspection from FreeBSD.

I did not have a parallel loop showing gstat output
or other such, relying on Mark Johnston's patches
for reporting any that are a problem for the subsystem(s)
involved. (It is also less I/O to not be running the
extra logs.)

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