From owner-freebsd-arm@freebsd.org Thu Jun 14 00:04:08 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 F21F51004576 for ; Thu, 14 Jun 2018 00:04:07 +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 2683E84135 for ; Thu, 14 Jun 2018 00:04:06 +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 w5E04IYF032397 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Jun 2018 17:04:19 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5E04I1n032396; Wed, 13 Jun 2018 17:04:18 -0700 (PDT) (envelope-from fbsd) Date: Wed, 13 Jun 2018 17:04:18 -0700 From: bob prohaska To: Mark Millard Cc: Warner Losh , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180614000418.GB24526@www.zefox.net> References: <20180613154826.GA24146@www.zefox.net> <20180613183730.GA24526@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 14 Jun 2018 00:04:08 -0000 On Wed, Jun 13, 2018 at 02:41:35PM -0700, Mark Millard wrote: > On 2018-Jun-13, at 11:37 AM, bob prohaska wrote: > > . . . > > Some of the combinations trigger the warning: > > > > warning: total configured swap (1048576 pages) exceeds maximum recommended amount (918256 pages). > > warning: increase kern.maxswzone or reduce amount of swap. > > As I remember, the "increase kern.maxswzone" only applies if one has > previously decreased it: the modern default is the maximum recommended > as I remember (allowing for for half the theoretical maximum swap). If > I remember right the code overrode attempts to set more than the > default, only setting less (when requested). (I've not re-validated > this claim via a code inspection in some time.) > > Quoting "man 8 loader" and its kern.maxswzone material, > > Note that swap metadata can be fragmented, which means that > the system can run out of space before it reaches the > theoretical limit. Therefore, care should be taken to not > configure more swap than approximately half of the > theoretical maximum. > > So it will potentially have more fragmentation problems fitting the > extra metadata that is involved in the same amount of total RAM. > > I will note that aarch64 and armv7 for the same amount of RAM use > very different "maximum recommended amount"s. On boot the RPI3 the system reports warning: total configured swap (1048576 pages) exceeds maximum recommended amount (918256 pages). warning: increase kern.maxswzone or reduce amount of swap. I've turned off the 1 GB of microSD swap, leaving only the 3 GB mechanical disk. On the RPI2 the report is warning: total configured swap (524288 pages) exceeds maximum recommended amount (469280 pages). warning: increase kern.maxswzone or reduce amount of swap A -j4 buildworld completes without trouble, even with the excess swap. > > which I've ignored, thinking the system will ignore excess swap space. > > Again: It will potentially have more fragmentation problems fitting the > extra metadata that is involved in the same amount of total RAM. > > > Is > > this mistaken? > > I expect so because of the metadata issue. (But some later > notes below go in another direction, making this possibly > not a unique source of overall behavior differences.) > > > It's pretty clear the system does not need more than about > > 1.5 GB of swap. Available swap devices are presently sized like so: > > I'd recommend not using a whole lot more than you need, at least > small enough (total) for it to not report the warning. > > One thing I wish FreeBSD had was an (approximate) "Maximum Observed > Swap Used" that could be queried or that some built-in tool would > monitor and report. Indeed. Vmstat will log activity, but finding the peak and relating it to OOM kills or other problems seems difficult without timestamps > There are times when slowly-performing swap is infinitely better than out-of-memory kills. The Raspberry Pi series seem a prime example. > > 3 GB mechanical disk > > 2 GB microSD flash > > 1 GB microSD flash > > 1 GB USB flash > > To make your experiments comparable, I'd recommend the same total > swap be used across the alternatives being tested and compared. > This may be biased to using a smaller swap space that all the > contexts can support. > > Going in another direction: The timing variations between the types > of media may mean that the mix of what is happening at the same time > changes for -j4 from one context to the next. This could get other > issues involved in why there are variations in the overall behavior. > > > Side note: I've used eMMC on an adapter in some microSD slots. I > had to "adjust" the Pine64+ 2GB case for the adapter that I used > to reach so such is not always an automatically-available option. > > . . . > > > Just for completeness for other readers (you may well be using swap > partitions) . . . > All of the swap experiments were with hard partitions. No swap files. The most glaring (to me) oddity is that both the USB flash and microSD flash are the same make and model name, all being Sandisk Extreme. The only obvious difference is the interface to the CPU. There's no hint of filesystem trouble with any media on either interface. On the RPI3 USB does not work for flash swap, but seems fine for mechanical swap. MicroSD flash swap seems to work without issue. Either kind of swap works on the RPI2. That makes no sense to me. Thanks for reading! bob prohaska