GPT vs MBR for swap devices

[bob prohaska]

On Wed, Jun 13, 2018 at 02:41:35PM -0700, Mark Millard wrote:
> 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. 

On boot the RPI3 the system reports
warning: total configured swap (1048576 pages) exceeds maximum recommended amount (918256 pages).
warning: increase kern.maxswzone or reduce amount of swap.

I've turned off the 1 GB of microSD swap, leaving only the 3 GB mechanical 
disk.

On the RPI2 the report is
warning: total configured swap (524288 pages) exceeds maximum recommended amount (469280 pages).
warning: increase kern.maxswzone or reduce amount of swap

A -j4 buildworld completes without trouble, even with the excess swap.


> > 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.

Indeed. Vmstat will log activity, but finding the peak and relating it
to OOM kills or other problems seems difficult without timestamps
> 
There are times when slowly-performing swap is infinitely better than
out-of-memory kills. The Raspberry Pi series seem a prime example.

> > 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.
> 
> . . .
> 
> 
> Just for completeness for other readers (you may well be using swap
> partitions) . . .
> 

All of the swap experiments were with hard partitions. No swap files.

The most glaring (to me) oddity is that both the USB flash and microSD
flash are the same make and model name, all being Sandisk Extreme. The 
only obvious difference is the interface to the CPU. There's no hint of
filesystem trouble with any media on either interface.

On the RPI3 USB does not work for flash swap, but seems fine for 
mechanical swap. MicroSD flash swap seems to work without issue.
Either kind of swap works on the RPI2. That makes no sense to me. 

Thanks for reading!

bob prohaska