From owner-freebsd-arm@freebsd.org Sun Jun 17 00:00:54 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 9D687100307E for ; Sun, 17 Jun 2018 00:00:54 +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 D020074C28 for ; Sun, 17 Jun 2018 00:00:53 +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 w5H010HL046581 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 16 Jun 2018 17:01:01 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5H010CB046580; Sat, 16 Jun 2018 17:01:00 -0700 (PDT) (envelope-from fbsd) Date: Sat, 16 Jun 2018 17:01:00 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180617000100.GA46435@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7AB401DF-7AE4-409B-8263-719FD3D889E5@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: Sun, 17 Jun 2018 00:00:54 -0000 On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: > bob prohaska fbsd at www.zefox.net wrote on > Sat Jun 16 19:12:22 UTC 2018 (some by reference > to other web pages, which is what I quote from > here) : > > > Presently, the divided swap layout fails during -j4 buildworld with > > "out of swap" kills during the more frantic portions of buildworld. > > > > When all swap is placed on a single 3 GB USB mechanical disk partition > > the "out of swap" errors go away. Similarly, when swap is placed entirely > > on the microSD card in two partitions, one the original 1 GB partition > > plus a second 2 GB partition, the "out of swap" errors dissapear. > > Since the "multiple swap partitions across multiple > devices" context (my description) is what has problems, > it would be interesting to see swapinfo information > from around the time frame of the failures: how much is > used vs. available on each swap partition? Is only one > being (significantly) used? The small one (1 GiByte)? > > A related, additional example to try? . . . > > Since you report needing around 1.2 GiByte of swap, what > happens if you have a split but both devices have, say, > 1.5 GiByte of swap space for the partition used? If I read > right, you could shrink the 2GiByte microSD card partition > and the 3 GiByte USB mechanical disk partition and then use > that pair as a test. (This also avoids the message about > having too much swap. Also, I'm avoiding having significant > size differences between the partitions used.) Technically, > without the split, either partition should be sufficient > without the other involved. In such a context, does the > split still fail? Or does it only fail when one partition > is too small to be sufficient by itself? > Thus far I think OOM kills have been happening long before either partition fills, but it'll take better logging than I have set up now to be sure. Is there a simple way to log recurrent swap measurements to a file? Swapinfo doesn't seem to have the right options. It would be particularly convenient if the swap usage info could be appended to the gstat log file. At one point I tried top -n -d all | grep Swap >> gstat.log (I'm using tcsh) but nothing was added to gstat.log and since there was no interest in swap usage totals I gave up. > These suggestions are going a different direction than the > I/O rate investigation but also having I/O rate information > would not hurt. But I/O rate information can not substitute > for the swapinfo output here. Nor can top cover what I'd be > looking for: per partition usage figures are required, not > just grand total swap-space usage. > > If you can suggest commands I'll gladly try them. As this little fiasco is playing out, it looks like the lesson for me is don't attempt to interleave swap. Old ideas die slow, but they do die... Thanks for reading, and all your help! bob prohaska