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]

[Quick top post: Possibly related bugzilla's for this area
are:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227609
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230402
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230454
.]

On 2018-Aug-12, at 10:15 AM, Mark Millard <marklmi at yahoo.com> wrote:

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