Date: Thu, 14 Jun 2018 09:53:57 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: bob prohaska <fbsd@www.zefox.net> Cc: Tom Vijlbrief <tvijlbrief@gmail.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: GPT vs MBR for swap devices Message-ID: <201806141653.w5EGrvpR045732@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <20180614164436.GA35161@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, Jun 14, 2018 at 11:24:50AM +0200, Tom Vijlbrief wrote: > > I am torturing myself by doing build worlds on an original rpi with just > > 256Mb memory. I used to use an usb hard disk for swap and for > > /usr/{src,obj} but that disk has died. > > > > Currently swapping on an NFS swap file (this Linux server also hosts > > /usr/{src,obj} ) which works surprisingly well. The user %cpu is much > > better when swap is heavily used (often > 90%) compared to the old usb disk > > setup. The latency of the NFS server is quite small, even with the slow > > 100mbit rpi Ethernet. > > > > It's understood that NFS for swap works. It's also a complex > and fragile solution for a seemingly-simple problem. Setting aside a > little bit of a microSD or USB storage device is cheaper, uses less power, > less hardware and has fewer failure points than NFS. I'd submit that it's > a better solution for infrequent needs like buildworld. > > My point is the observation that using USB flash for swap does not seem > to work on RPI3, although microSD flash does work, along with USB mechanical > drives. > > The fact the USB flash swap does seem to work on an RPI2 suggests that > there's nothing inherently wrong with USB flash as a swap medium. In > particular, I'm becoming skeptical of claims that modern USB flash > is too slow on write for use as swap. > > Thanks for reading, I would be very interested in seeing if resizing the swap partition in the example that greatly exceeds what the system expects as a max total swap helps to bring the OOM issue under control. I think the state of things is such that if you use up the max usable swap space on the first swap device, only that swap device well ever be used. I do not believe there is any attempts what so ever to split the allocation up so that you use the first fraction of each device. > > bob prohaska > > > > Op wo 13 jun. 2018 23:42 schreef Mark Millard via freebsd-arm < > > freebsd-arm@freebsd.org>: > > > > > On 2018-Jun-13, at 11:37 AM, bob prohaska <fbsd at www.zefox.net> 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. (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 > > > 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. 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. > > > . . . > > > > > > > > > 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=206048 > > > > > > > > > (OOM process kills were not one of the issues for bugzilla 206048. > > > But there were other problems for swap files.) > > > > > > === > > > Mark Millard > > > marklmi at yahoo.com > > > ( dsl-only.net went > > > away in early 2018-Mar) > > > > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201806141653.w5EGrvpR045732>