Date: Fri, 2 Mar 2018 17:02:09 -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: <201803030102.w231298R032483@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <20180303004315.GB37148@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Getting that 32 bit version of FreeBSD running on the RPI3 would prove out my theory. 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'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?201803030102.w231298R032483>