Date: Sun, 12 Aug 2018 10:15:18 -0700 From: Mark Millard <marklmi@yahoo.com> To: Mark Johnston <markj@FreeBSD.org>, Warner Losh <imp@bsdimp.com> Cc: Trev <freebsd-arm@sentry.org>, bob prohaska <fbsd@www.zefox.net>, John Kennedy <warlock@phouka.net>, Jamie Landeg-Jones <jamie@catflap.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: 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] Message-ID: <F43ED9FB-6AF2-4069-9A4E-15E134593174@yahoo.com> In-Reply-To: <64798536-4ba5-24e9-304b-30cfb5b702d0@sentry.org> References: <EC74A5A6-0DF4-48EB-88DA-543FD70FEA07@yahoo.com> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <CANCZdfpKOTBrxiNhaeHHRp-2iw5a4eXt%2Bmd_1LTD-c0%2BAE6qxg@mail.gmail.com> <20180809153710.GC30347@www.zefox.net> <CANCZdfrC0s8X-LxJmrDmkxmz%2BGUMNsHSMpBEQmp1S5ahcvptpg@mail.gmail.com> <20180810044426.GB32974@www.zefox.net> <20180811163209.GA38922@www.zefox.net> <64798536-4ba5-24e9-304b-30cfb5b702d0@sentry.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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/lib= clang/Sema/SemaDeclAttr.o Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/Sema/SemaDeclCXX.o Building = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/clang/lib= clang/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:=20 ******************** 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:=20 ******************** *** [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=3D0 md=3DHOST spd=3DHIGH= (480Mbps) pwr=3DSAVE (0mA) ugen1.1: <Generic OHCI root HUB> at usbus1, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DSAVE (0mA) ugen0.2: <OWC Envoy Pro mini> at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH = (480Mbps) pwr=3DON (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.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F43ED9FB-6AF2-4069-9A4E-15E134593174>