Date: Fri, 2 Mar 2018 17:46:43 -0800 From: bob prohaska <fbsd@www.zefox.net> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: Ian Lepore <ian@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, bob prohaska <fbsd@www.zefox.net> Subject: Re: Is maximum swap usage tunable? Message-ID: <20180303014643.GD37148@www.zefox.net> In-Reply-To: <201803030102.w231298R032483@pdx.rh.CN85.dnsmgr.net> References: <20180303004315.GB37148@www.zefox.net> <201803030102.w231298R032483@pdx.rh.CN85.dnsmgr.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... > 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? > 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. > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180303014643.GD37148>