Date: Sun, 12 Aug 2018 10:59:48 -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: <507FC6E0-6EDB-4A0D-A9A6-DD03B50A1DA3@yahoo.com> In-Reply-To: <F43ED9FB-6AF2-4069-9A4E-15E134593174@yahoo.com> 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> <F43ED9FB-6AF2-4069-9A4E-15E134593174@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Quick top post: Possibly related bugzilla's for this area are: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227609 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230402 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230454 .] 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). >=20 > 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). >=20 > I expect that this case shows that the problem does not > require I/O latency problems to be involved. >=20 > The only console message was: >=20 > 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 >=20 > The build had been started at: 01:44:59 so the failure > was around 7 hours 45 minutes into the build. >=20 > The build log shows: >=20 > 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 > ******************** >=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 >=20 > ******************** > *** [Sema/SemaDecl.o] Error code 254 >=20 >=20 > Description of the context . . . >=20 > 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.) >=20 > 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. >=20 > (With an edit of that /etc/fstab the microSDHC can boot > standalone: I keep it tracking.) >=20 > # 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) >=20 > 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. >=20 > 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.) >=20 > 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.) >=20 > 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. >=20 > 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.) >=20 =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?507FC6E0-6EDB-4A0D-A9A6-DD03B50A1DA3>