From owner-freebsd-arm@freebsd.org Wed Jun 13 21:41:48 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 AC6A9101A522 for ; Wed, 13 Jun 2018 21:41:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-4.consmr.mail.bf2.yahoo.com (sonic301-4.consmr.mail.bf2.yahoo.com [74.6.129.43]) (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 5444A7DF8F for ; Wed, 13 Jun 2018 21:41:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Rju9YWoVM1nQRHy1ngIYq_cbS9DdO17ZcA5c1vK0d4EJucApNWTMz0DG7fJj9c7 h.pLAmoyYXbBp8ixzgycvGyxjht0U9t087.McajCJVWv6OK.I6VYMzDmi_W5_tsHqxIiBEjhPxtA 1poFfjGLEFEfbuZ6NMJ57iYWMvMnEN2EV11CkI8Fm7d399v9W9jjr.5IuniNO2_iX9yPr0zg6y5i k92sRZZtUydWPE27RvsDLteNMHBFnovGePV06Gm6IRHuQsvvac6s_D4uh2cmAuDrcUwftPm60QUD TS9KQiitVGDkKGIVQkSYFbqMIYp2asSHswBgdFy6xTtVEAI77vIiOJFwlpHS2m5JAYRJz1.K2I1g OF8fEDNxbHBSYXHKEnk5DepsWMyOEGbmyr8s6KUldO6EfYv_hNBR5vVXuANyyd3ChGeJIlttNOht urjzhAMOrI6ZniF4q_iC5ccJ7vrVDcLxshhJfI2WXfSY1mOP2Xch8KdYK6hSj7ApNvhgTrlOYVNQ WkQS16OtNEbzZQthkzYtkUAZ1FfLrceWQmlAMfoaYWH5kZt7hD3_gy2FfH0DVGkGFt6CCPaJQyAy IKhEPKq4EUHSimVZbOWreYBvOyo7CGHjeR0ykDybCL4snfPzX4YngLCPtMHIsxVdCcUEvvcHXPsF 0d8PlaPB_kg.Pq7iPAD.9Ydsvff4zWgDIIZrsMfO2n6LV9jJoMsZhlc1HX2e4zGr7rf2sTBOBdK6 IKvO.lnSj9mHag.NW2_7Gn_l8fTIU915nHqWfoNnKf.o_ypv6NgmeO4V3NJ8EJi1ToMh0ZaC6ABd vwyFFNc2PNRo3bdQuzYbNljuRnkq_AE3GYb5jXnwWw6SytYdJe7W41RLcV2NMXpnZbn8cGjtKnEG 6a3iXe60jVipSVu140W8Am1qJ4TtalKNFspgQPK.3yoNSe9XnQGOS44g.02NryhIqQHN0YZk3FPD 8aJ1DAuJ7WuDHLhDnk4qEm_2ap4TiRKJIaEQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Wed, 13 Jun 2018 21:41:42 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.109]) ([70.189.131.151]) by smtp419.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9ba3756b48b75b5f6df2ed44313c0ea4; Wed, 13 Jun 2018 21:41:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180613183730.GA24526@www.zefox.net> Date: Wed, 13 Jun 2018 14:41:35 -0700 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180613154826.GA24146@www.zefox.net> <20180613183730.GA24526@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) 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: Wed, 13 Jun 2018 21:41:48 -0000 On 2018-Jun-13, at 11:37 AM, bob prohaska wrote: . . . > Some of the combinations trigger the warning: >=20 > 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=20 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. (Compare an armv7 rpi2 to an aarch64 rpi3 by adding enough swap to get the notice, for example. The rpi3 allows far more swap space as I remember.) This variability is not obvious from the man page's material. > which I've ignored, thinking the system will ignore excess swap space. Again: It will potentially have more fragmentation problems fitting the=20= extra metadata that is involved in the same amount of total RAM. > Is=20 > 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=20 > 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. At times I've made variants of top that displayed such based on the figures it uses for its swap line. I've made judgements about -jN choices and swaps space sizes based on what I've observed for various contexts that I use/do repeatedly and for "large" things that I do rarely but that can fail in my normal configuration. > 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. > The original plan was to use the two 1 GB flash partitions in the hope > they'd interleave, but that does not work at all. The microSD flash > swap seems to work fine. I was wondering if the USB mechanical swap > might point to trouble in the USB side of things, but it does not.=20 . . . Just for completeness for other readers (you may well be using swap partitions) . . . I also recommend swap partitions instead of swap files. See, for example: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 (OOM process kills were not one of the issues for bugzilla 206048. But there were other problems for swap files.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)