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>