From owner-freebsd-arm@freebsd.org Sun Aug 12 17:15:31 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85DB21076BCE for ; Sun, 12 Aug 2018 17:15:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-9.consmr.mail.gq1.yahoo.com (sonic307-9.consmr.mail.gq1.yahoo.com [98.137.64.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1BE070AA7 for ; Sun, 12 Aug 2018 17:15:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: gOr84X4VM1k6lDzKO94jPrtCrSUncgscEFyfF6edQ9kdhf0i8o4lMOMVIYLgngQ aWW6xD2cElSRC6rsqMeXnKuCfbFIEKhw0LpGf8tDgkErMYmxxB716L7SXZNXTnfUdEzMsC0tBvAG V70rJz6ZhxlYLoEdU0THv_C2h6zDW_KYxynfYknsHWiyOQCYcaExrVHL100H2ne9ZPzl2ez3ULEG Klr3obgKvwqGyYcxJjs1yi_BninlMXPfcu_2q9KenohkUYEmCsS35iiP82YSu88PWkAyNE4CiV5W uxv8_YDvZKPw4tTYIevDPIjpf6qchmdf1NWUw4ugb4Jyp6TNYO6iSf1YsahzhsCL1maqHK6PC0j0 HMsBOK7Oc4sJL64l5k7orMNKzlQAQoM__lyG1xWekRiYJSODK.Fi.ISGlkrJ.vbbIyuBLWoB.nHS NGBX8vxm6JSFji6s3KgCl0l00vc3R5jb_hdK.UXCOit8K5huNV.U_46b3GGcB0u4TKZU2KJkqIdI JonW56o6YxbEJQIlvnB8gwNogEoyhXEu_FyAfH.RKJ6qyHbc7mohYknkGblDMM9rGJBZNzR3yaxl PNCuD7YWygH7roSJkfE4snqbYIOVHzte0rvo4uePV8m4DAeHsk_9HQ2CyOksWnFdc3CrEEjReEwo VLYE8w1mPEZ6_cgfHm88YJeWbUzbHW_BkJCufG6Xz8VQH_OJXDa_MKONFxQ7xdOXqs_kWoV5NKz_ eZqOuEP4HWnzgWWIvZcC00BgPw4zPjnD24EEMsowJx2dxv2G0oV3YMIio_BiC5UzZhQW02Z7yV5M DdPgMTMyI5EKFVWMXuoc7fUaxDXjdcvLe0C5VBfOKn99peeCYwimqebI5Z4HLc9hb8rcbogtThpR HSIgJmJXvd8PGRcr5ZYTBRTU2zZZDbLW55sBmwZqAFIqSeX.X4hHpGJoCujiILuf9WQyShPvSN0f wo7qjbKXdyZ.k8KJMGnoUnKARK94y4_sK7viM4YKLLOqOn1IVhZfJ.yU83LqQOY2r5dk7aRK4gA_ sM6zatrLv3TzTqznUPIESGysD Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Aug 2018 17:15:24 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp423.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c4dbbba95c7daf1ca19611335d7b457d; Sun, 12 Aug 2018 17:15:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) 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] From: Mark Millard In-Reply-To: <64798536-4ba5-24e9-304b-30cfb5b702d0@sentry.org> Date: Sun, 12 Aug 2018 10:15:18 -0700 Cc: Trev , bob prohaska , John Kennedy , Jamie Landeg-Jones , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <20180809065648.GB30347@www.zefox.net> <20180809152152.GC68459@raichu> <20180809153710.GC30347@www.zefox.net> <20180810044426.GB32974@www.zefox.net> <20180811163209.GA38922@www.zefox.net> <64798536-4ba5-24e9-304b-30cfb5b702d0@sentry.org> To: Mark Johnston , Warner Losh X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 17:15:31 -0000 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: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH= (480Mbps) pwr=3DSAVE (0mA) ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DSAVE (0mA) ugen0.2: 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)