Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Jun 2018 09:44:36 -0700
From:      bob prohaska <fbsd@www.zefox.net>
To:        Tom Vijlbrief <tvijlbrief@gmail.com>
Cc:        Mark Millard <marklmi@yahoo.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, bob prohaska <fbsd@www.zefox.net>
Subject:   Re: GPT vs MBR for swap devices
Message-ID:  <20180614164436.GA35161@www.zefox.net>
In-Reply-To: <CAOQrpVf5RZsX-hvHTpwVYMj9G76gt3moRvirnb56Eq77sZsE2w@mail.gmail.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> <CAOQrpVf5RZsX-hvHTpwVYMj9G76gt3moRvirnb56Eq77sZsE2w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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,

bob prohaska


> 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?20180614164436.GA35161>