From owner-freebsd-arm@freebsd.org Tue Jul 31 18:19:09 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 1029F1060D4C for ; Tue, 31 Jul 2018 18:19:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7051D759F1 for ; Tue, 31 Jul 2018 18:19:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6VIJN8X095217 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 11:19:24 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6VIJNbQ095216; Tue, 31 Jul 2018 11:19:23 -0700 (PDT) (envelope-from fbsd) Date: Tue, 31 Jul 2018 11:19:23 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments Message-ID: <20180731181923.GC94742@www.zefox.net> References: <20180723155311.GB45726@www.zefox.net> <4ED9B658-A5A8-4BA6-9412-EBB7150B4B66@yahoo.com> <20180723190257.GA47869@www.zefox.net> <76BCFCB9-1071-4557-9FDE-017444ADBF42@yahoo.com> <20180725232453.GA57716@www.zefox.net> <20180731054712.GA92917@www.zefox.net> <20180731153531.GA94742@www.zefox.net> <908FB299-07CF-4E88-9C18-298CA357AD01@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <908FB299-07CF-4E88-9C18-298CA357AD01@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Tue, 31 Jul 2018 18:19:09 -0000 On Tue, Jul 31, 2018 at 10:51:51AM -0700, Mark Millard wrote: > > > On 2018-Jul-31, at 8:35 AM, bob prohaska wrote: > > > On Tue, Jul 31, 2018 at 10:31:33PM +1000, Trev wrote: > >> bob prohaska wrote on 31/07/2018 15:47: > >> > >>> It would be most interesting to see what happens if OOMA > >>> could be turned off. Is that possible? > >> > >> Possibly, but you might find you're treating the symptom(s) rather than > >> the cause(s) ... something must be triggering the condition whether > >> correctly or not. > > > > That's my point. To determine if OOMA is triggered correctly or not. I'm starting > > to think not. > > > > The reason is the dependency on swap layout (mixed USB/microSD vs all one or the > > other) and the fact that OOMA kills don't seem to coincide with periods of > > maximum storage read/write delay, which is the conventional explanation for > > why OOMA kills happen in the first place. If turning off OOMA allows buildworld > > to complete successfully it suggests OOMA isn't correctly implemented. > > Your rpi2 report said: > > > In this particular case all swap is on USB, in a single > > 2 GB partition. > > which for that example indicates that swap layout being split > was not involved. (But there is the potential too-large issue.) > That's true, I can't test mixed swap on that setup. My point was that formerly (months ago) 2GB of USB swap worked for -j4 buildworld. > Have you had other examples of non-split swap layout getting > OOMA kills? If yes, what types of contexts? [Especially any that > do not have observed huge latencies or to evidence of device > failures (retries required).] Any on rpi3? Any others on rpi2? > Yes. Another storage configuration for the Pi3 (not installed at the moment) has three 1 GB swap partitions on USB and three 1 GB swap partitions on microSD. In that case buildworld fails from OOMA using 2 GB mixed or microSD swap but succeeds using USB swap. That surprised me in that the microSD cards are the same. The USB device in that case is 3.0 vs 3.1, so different in some small way. > As for swap use, do you have any tmpfs or other files systems > that are memory based that also use swap if they grow too > big (and are configured to allow such growth)? > No memory-based filesystems in use. > Thanks for reading! bob prohaska