Date: Thu, 14 Jun 2018 11:24:50 +0200 From: Tom Vijlbrief <tvijlbrief@gmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: bob prohaska <fbsd@www.zefox.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: GPT vs MBR for swap devices Message-ID: <CAOQrpVf5RZsX-hvHTpwVYMj9G76gt3moRvirnb56Eq77sZsE2w@mail.gmail.com> In-Reply-To: <B3935E25-3B75-4813-832D-6A3DD631CF13@yahoo.com> References: <20180613154826.GA24146@www.zefox.net> <CANCZdfqY7-knHsiD_qwPZLbE8j2Pm7Q8SbANgbgKaOaFPH5O_Q@mail.gmail.com> <20180613183730.GA24526@www.zefox.net> <B3935E25-3B75-4813-832D-6A3DD631CF13@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOQrpVf5RZsX-hvHTpwVYMj9G76gt3moRvirnb56Eq77sZsE2w>