GPT vs MBR for swap devices

Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net
Thu Jun 14 16:54:00 UTC 2018


> On Thu, Jun 14, 2018 at 11:24:50AM +0200, Tom Vijlbrief wrote:
> > 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.
> > 
> 
> It's understood that NFS for swap works. It's also a complex
> and fragile solution for a seemingly-simple problem. Setting aside a
> little bit of a microSD or USB storage device is cheaper, uses less power,
> less hardware and has fewer failure points than NFS. I'd submit that it's
> a better solution for infrequent needs like buildworld.
> 
> My point is the observation that using USB flash for swap does not seem 
> to work on RPI3, although microSD flash does work, along with USB mechanical 
> drives.  
> 
> The fact the USB flash swap does seem to work on an RPI2 suggests that 
> there's nothing inherently wrong with USB flash as a swap medium. In 
> particular, I'm becoming skeptical of claims that modern USB flash 
> is too slow on write for use as swap.  
> 
> Thanks for reading,

I would be very interested in seeing if resizing the swap partition
in the example that greatly exceeds what the system expects as a
max total swap helps to bring the OOM issue under control.

I think the state of things is such that if you use up the
max usable swap space on the first swap device, only that
swap device well ever be used.  I do not believe there is
any attempts what so ever to split the allocation up so
that you use the first fraction of each device.

> 
> bob prohaska
> 
> 
> > Op wo 13 jun. 2018 23:42 schreef Mark Millard via freebsd-arm <
> > freebsd-arm at 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 at freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> > >
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org


More information about the freebsd-arm mailing list