GPT vs MBR for swap devices

Mark Millard marklmi at
Wed Jun 13 21:41:48 UTC 2018

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

(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)

More information about the freebsd-arm mailing list