From owner-freebsd-arm@freebsd.org Tue Jun 26 22:28:26 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 C6B80101E77F for ; Tue, 26 Jun 2018 22:28:25 +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 4107787186 for ; Tue, 26 Jun 2018 22:28:25 +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 w5QMSZ5Z021847 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jun 2018 15:28:36 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5QMSZka021846; Tue, 26 Jun 2018 15:28:35 -0700 (PDT) (envelope-from fbsd) Date: Tue, 26 Jun 2018 15:28:34 -0700 From: bob prohaska To: Mark Millard Cc: Jamie Landeg-Jones , Warner Losh , freebsd-arm , bob prohaska Subject: Re: RPI3 swap experiments, was Re: GPT vs MBR for swap devices Message-ID: <20180626222834.GA20270@www.zefox.net> References: <20180623143218.GA6905@www.zefox.net> <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> <20180624231020.GA11132@www.zefox.net> <20180626052451.GA17293@www.zefox.net> <201806261040.w5QAeBKq035183@donotpassgo.dyslexicfish.net> <20180626151843.GD17293@www.zefox.net> <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3525D7C7-F848-45A1-BD85-2DAC895DF48C@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 22:28:26 -0000 On Tue, Jun 26, 2018 at 01:15:54PM -0700, Mark Millard wrote: > On 2018-Jun-26, at 8:18 AM, bob prohaska wrote: > > > On Tue, Jun 26, 2018 at 07:37:59AM -0700, Mark Millard wrote: > >> > >> > >> . . . > >> > >> As I remember, Bob P. Did reproduce drive errors even without > >> the problem drive being used for swapping. This too suggests > >> (A) as separate activity. > >> > > Indeed, it is a requirement. If the suspect device is used for swapping > > OOMA kills prevent the test from progressing to the point of failure. > > > > Looking back at http://www.zefox.net/~fbsd/rpi3/swaptests/ > and information about /dev/da0 rive errors it does not > appear that a combination with: > > A) sufficient swap (> 1.5 GiByte total?) but no use of swap on > any partition on /dev/da0 > and: > B) use of /dev/da0 for /usr/ and /var/ > and: > C) Records from the console showing errors (or notes > indicating lack of such errors). > > exists. So I was remembering incorrectly. > > I'm not claiming such a combination is the best direction for > the next tests, but absent such tests there is no > compare/contrast to know if /dev/da0 would still get errors > despite the system having sufficient swap present on other > drives. Thus, I would not go so far as "is a requirement" on > the evidence available. > I just didn't bother to record successful runs. I'm logging one now. > We do have evidence for the system having insufficient swap > space: this context seems to have the current status "is > sufficient but might not be necessary" for /dev/da0 > getting drive errors. > Not sure I understand here. Basically there seem to be three cases: Enough swap not on da0, -j4 buildworld completes. Any swap on da0, -j4 buildworld is killed by OOMA Not enough swap not on da0, -j4 buildworld crashes the machine eventually. Are there other combinations I've overlooked? The first two don't seem worth repeating, at least not often. > > As for simpler contexts, one that would swap but would be > far simpler a context than buildworld buildkernel might be > something like using the stress port via options like: > > stress -d 2 -m 3 --vm-keep > > (The option values likely could need adjustment from context > to context to match available resources. The above is not > carefully tailored to your context or a modern context. > It dates back to 2016-Jan-22 for showing vnode based swap > failures in a 1 GiByte RAM + 1 GiByte swap-file context > [inside virtualbox on amd64 hardware]: see comment 3 of > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 .) > > This is new to me and entirely separate from Peter Holm's stress2. It compiled without a hitch and seems worth a try. Thank you! bob prohaska