Date: Sat, 1 Sep 2018 19:51:54 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024") Message-ID: <F3AF3A89-322E-4048-A758-4276C1A1BEA0@yahoo.com> In-Reply-To: <20180901230233.GA42895@www.zefox.net> References: <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <FC0798A1-C805-4096-9EB1-15E3F854F729@yahoo.com> <20180813185350.GA47132@www.zefox.net> <FA3B8541-73E0-4796-B2AB-D55CE40B9654@yahoo.com> <20180814014226.GA50013@www.zefox.net> <CANCZdfqFKY3Woa%2B9pVS5hika_JUAUCxAvLznSS4gaLq2kKoWtQ@mail.gmail.com> <20180815013612.GB51051@www.zefox.net> <CANCZdfoB_AcidFpKT_ZmZWUFnmC4Bw55krK%2BMqEmmj=f9KMQ2Q@mail.gmail.com> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Sep-1, at 4:02 PM, bob prohaska <fbsd at www.zefox.net> wrote: > On Wed, Aug 15, 2018 at 03:55:04PM -0700, bob prohaska wrote: >>=20 >> When I started this goose chase, after zero problems with RPI2, I = thought the >> issue was arm64-related and might be of some fundamental importance. >>=20 >> Thanks to many people I now understand it's a confluence of USB and = flash memory >> artifacts, made evident by the demands of clang6. Elsewhere I noted = that I'm seeking >> "the robustness of a Mars rover, using a rack server OS on a = cellphone motherboard". >>=20 >=20 > With r338342 and > vm.pageout_oom_seq=3D"1024" > in /boot/loader.conf the RPI3 is a bit closer to a Mars Rover. > No panics, crashes or USB errors, -j4 buildworld runs to completion. > When swap usage goes over about 50% the system slows, but doesn't give = up. > There are six 1 GB swap partitions available, 3 on USB and 3 on = microSD. >=20 > Log files are at > http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/ > for the combinations tried so far. http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/2gbsd/swapscript.log shows things like: dT: 10.043s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 126 19 122 2.3 107 2034 3.3 0 0 = 0.0 29.2 da0 0 67 0 0 0.0 67 1126 2.5 0 0 = 0.0 16.6 da0f 0 59 19 122 2.3 40 909 4.7 0 0 = 0.0 14.7 da0g as well as: dT: 10.004s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 4 412 32 324 11.2 380 2945 7.9 0 0 = 0.0 80.2 mmcsd0 0 1 1 26 4.7 0 0 0.0 0 0 = 0.0 0.4 da0 4 412 32 324 11.5 380 2945 8.0 0 0 = 0.0 80.8 mmcsd0s2 2 205 15 160 10.6 190 1453 8.0 0 0 = 0.0 78.7 mmcsd0s2d 2 207 17 165 12.3 190 1491 8.0 0 0 = 0.0 78.6 mmcsd0s2e 0 0 0 0 0.0 0 1 17.5 0 0 = 0.0 0.2 mmcsd0s2a 0 0 0 0 0.0 0 1 17.6 0 0 = 0.0 0.2 ufs/rootfs 0 1 1 26 4.8 0 0 0.0 0 0 = 0.0 0.4 da0g It is not clear what partitions were in use for what types of data. da0f, da0g, mmcsd0s2d, and mmcsd0s2e: are they all swap partitions? If yes, then the the test log does not appear to be a "2gbsd" test. Ignoring such points: Are these tests using the same devices that logged errors to the console in all that prior testing? If yes: Having such errors stop is potentially interesting. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F3AF3A89-322E-4048-A758-4276C1A1BEA0>