Date: Sun, 22 Jul 2018 23:35:27 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Trev <freebsd-arm@sentry.org> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: RPI3 swap experiments Message-ID: <20180723063526.GA45726@www.zefox.net> In-Reply-To: <bc8da02c-4465-9634-6fd0-0af4c63aa49d@sentry.org> References: <20180629155131.GA35717@www.zefox.net> <c6b8842a-fcc5-8e11-5a03-ba76eb3c5dea@sentry.org> <20180629233937.GC35717@www.zefox.net> <0f137e06-214a-3e8c-a216-f061ec04ac2c@sentry.org> <20180630005145.GA43801@www.zefox.net> <6f3406e2-71f3-d0c2-2b65-703e1a1d3c25@sentry.org> <8e92b2b7-da61-3efb-7231-9fac76b2c1d4@sentry.org> <ba33d8a7-a849-3893-8016-0765ebe1c51f@sentry.org> <2deaaec3-f78f-0b09-5ca7-27e14c6979f9@sentry.org> <bc8da02c-4465-9634-6fd0-0af4c63aa49d@sentry.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 22, 2018 at 06:50:42PM +1000, Trev wrote: > Trev wrote on 04/07/2018 07:09: > > Ok, the final, final swap experiment. > > > > I created a 2G swap partition on the SDCard: > > > > gpart show > > =>?????????? 63?? 31116225?? mmcsd0?? MBR?? (15G) > > ?????????????? 63?????????? 2016?????????????????? - free -?? (1.0M) > > ?????????? 2079?????? 102400???????????? 1?? fat32lba?? [active]?? (50M) > > ?????? 104479?? 31011809???????????? 2?? freebsd?? (15G) > > > > =>???????????? 0?? 31011809?? mmcsd0s2?? BSD?? (15G) > > ???????????????? 0?? 25165824???????????????? 1?? freebsd-ufs?? (12G) > > ?? 25165824???? 4194304???????????????? 2?? freebsd-swap?? (2.0G) > > ?? 29360128???? 1651681?????????????????????? - free -?? (806M) > > > > and, yes, it still died during make -j4 buildworld: > > > > Jul?? 3 22:15:24 rpi3 kernel: pid 57011 (c++), uid 0, was killed: out of > > swap space > > I replaced the SanDisk 16G Ultra (Speed Class 10, UHS Speed Class 1, > minimum 10MB/s seq write) used above with a SanDisk 32G Extreme (Speed > Class 10, UHS Speed Class 3, minimum 30MB/s seq write) micro-SD card and > now the above configuration survives make -j4 buildworld to end > successfully. Twice so far. > > The configuration is a little different because of the extra space: > > root@rpi3:~ # gpart show mmcsd0s2 > => 0 62229473 mmcsd0s2 BSD (30G) > 0 12582912 1 freebsd-ufs (6.0G) [root s2a] > 12582912 4194304 2 freebsd-swap (2.0G) [swap s2b] > 16777216 12582912 4 freebsd-ufs (6.0G) [home s2d] > 29360128 32869345 5 freebsd-ufs (16G) [usr s2e] > > Note: the SanDisk 32G Extreme I bought at the local (rural) OfficeWorks > is "old" stock as it does not have the "application performance class > rating" (A1) on it which signifies minimum random read of 1500 IOPS and > minimum random write of 500 IOPS. There's also an A2 which signifies > minimum random read of 4000 IOPS and minimum random write of 2000 IOPS. > > Everything subjectively seems snappier. Watching gstat randomly during > buildworld I saw no busy percentage greater than 101% and no queue > greater than 17, whereas with the Ultra card, I often saw 200-400% with > large queues in the 100s. Take the observations in this paragraph with a > grain of evidence-free, anecdotal salt. > > Trying to determine the real difference between Ultra and Extreme cards > was difficult. The best I could come up with were unsupported claims > that the Extreme series contain "card controller technology that allows > parallel processing of reads and writes" which might just be confusing > UHS-I/HC-I (half-duplex) and UHS-II/HC-II (full duplex) bus interfaces. > There is some reason to think "newer" Sandisk Extreme devices differ, perhaps in a bad way, from older devices. The older device in my tests is model SDCZ80-064G and is simply labeled USB3.0. The newer, troublesome device is model SDCZ800-064G and is labeled Extreme Go USB 3.1. There are reports that the Extreme Go is slower, advising to buy the older devices if possible. The USB3.1 flash drive is back in test, with the results of a j4 buildworld under r336567 at http://www.zefox.net/~fbsd/rpi3/swaptests/r336567/ The worst case results are still fairly dismal, close to a minute. All the swap was on microSD, so OOMA didn't strike and buildworld completed successfully. Near as I can tell no errors were reported on the console. Thanks for reading, bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180723063526.GA45726>