GPT vs MBR for swap devices

Tom Vijlbrief tvijlbrief at
Thu Jun 14 09:25:03 UTC 2018

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 at>:

> On 2018-Jun-13, at 11:37 AM, bob prohaska <fbsd at> 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:
> (OOM process kills were not one of the issues for bugzilla 206048.
> But there were other problems for swap files.)
> ===
> Mark Millard
> marklmi at
> ( went
> away in early 2018-Mar)
> _______________________________________________
> freebsd-arm at mailing list
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at"

More information about the freebsd-arm mailing list