Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Mar 2018 17:52:32 -0800 (PST)
From:      "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>
To:        bob prohaska <fbsd@www.zefox.net>
Cc:        Ian Lepore <ian@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: Is maximum swap usage tunable?
Message-ID:  <201803030152.w231qXFA032676@pdx.rh.CN85.dnsmgr.net>
In-Reply-To: <20180303014643.GD37148@www.zefox.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, Mar 02, 2018 at 05:02:09PM -0800, Rodney W. Grimes wrote:
> > > On Fri, Mar 02, 2018 at 10:15:57AM -0700, Ian Lepore wrote:
> > > 
> > > > You forgot a cause: (5) swap is on an sdcard where taking 30-90 seconds
> > > > to complete an IO is "normal".
> > > > 
> > > FWIW, the Sandisk Extreme USB flash drive is claimed to be considerably
> > > faster than that, ~2MB/sec random write, at least per
> > > http://usb.userbenchmark.com/SanDisk-Extreme-USB-30-16GB/Rating/1301
> > > One hopes(!) that the microSD cards of the same name are simlar.
> > > 
> > > > Making it even more fun, there's a sort of (5.5) bullet: an sdcard can
> > > > "lend" its horrible performance to every other storage device in the
> > > > system. ?If there is a ton of IO queued up to the sd device (such as
> > > > when .o files from a a make -j are ending up there) then all the
> > > > buffers in the system get stacked up in the sd device's bio queue and
> > > > IO to other devices suffers.
> > > >
> > > A j4 buildworld on an RPI2 running -current seems to work much better
> > > than j2 on an RPI3, both using the same Sandisk flash devices. The Pi2
> > > has /usr, /var /tmp and swap on USB flash, the Pi3 has /tmp and half
> > > the swap on microSD, with /usr, /var and the other half of swap on
> > > USB flash. Thus, /tmp and all of swap are on the same device for the
> > > Pi2, while /tmp and only half the swap are on the same device on the Pi3.
> > > It was expected the Pi3 should work better than the Pi2, but the opposite
> > > seems to be observed.
> > 
> > I would actually expect the opposite, but not for an obvious reason,
> > the RPI2 is running a 32 bit version of FreeBSD, and the RPI3 is
> > running a 64 bit version.  These are memory constrained devices,
> > and my theory is that the wasted memory used for pointers that can
> > never address more than the 2G of physcial space on the RPI3 are
> > killing your memory foot print, and killing your build.
> > 
> Any idea how much memory gets wasted? Right now the Pi3 kernel is
> smaller than that of the Pi2, 
> -r-xr-xr-x  1 root  wheel  7142608 Feb 25 17:11 /boot/kernel/kernel
> versus
> -r-xr-xr-x  1 root  wheel  9426388 Feb 26 22:31 /boot/kernel/kernel
> on the Pi2. Seems like that ought to at least help...

This is an artifact of the number of devices supported being
short on the RPi3.

> > Getting that 32 bit version of FreeBSD running on the RPI3 would
> > prove out my theory.
> >
> How much and what kind of work is required?

>From what jhb said the other day it is minor clean up details,
and I believe someone else has wip in progress to clean up
some of those details.   

> 
> > In my mind it makes 0 sense to run a 64 bit OS on a device that
> > physically has less than 4G of memory, other than as an exercise
> > in yes, we can make the 64 bit code run on that cpu, but for
> > real work usage it makes no practical sense.  I also suspect
> > that the cortex CPU in that thing can run 32 bit code a wee
> > bit faster than 64 bit code other than large data moves...
> >
> I agree, and remember your observations along those lines some
> time ago. The only reason I'm fooling with arm64 is that the older
> Pi2 seems NLA and the Pi3 is, or soon will be, the only option.
> A Pi3 running Raspbian, on which I'm typing this, is a quite decent
> little workstation. It's using USB flash (old and slow, by the way)
> for swap, but has a Sandisk Extreme microSD card.

And that Raspbian is 32 bit :-D

> > > > I've always thought the new(ish) IO scheduler stuff should be able to
> > > > help with that in some way, but I never get around to looking at it.
> > > > 
> > > > 
> > > I'd be pleased to do any testing I can, if it helps.
> > > 
> 
> Thanks for reading,
> 
> bob prohaska
-- 
Rod Grimes                                                 rgrimes@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803030152.w231qXFA032676>