Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Sep 2018 01:32:17 -0700
From:      bob prohaska <fbsd@www.zefox.net>
To:        Mark Millard <marklmi@yahoo.com>
Cc:        freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net>
Subject:   Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024")
Message-ID:  <20180902083217.GA44384@www.zefox.net>
In-Reply-To: <F3AF3A89-322E-4048-A758-4276C1A1BEA0@yahoo.com>
References:  <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> <F3AF3A89-322E-4048-A758-4276C1A1BEA0@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 01, 2018 at 07:51:54PM -0700, Mark Millard wrote:
> 
> 
> 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:
> >> 
> >> 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.
> >> 
> >> 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".
> >> 
> > 
> > With r338342  and
> > vm.pageout_oom_seq="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.
> > 
> > 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.
> 
The swap partitions are identified in the swapinfo data following the gstat and date
output, in this case mmcsd0s2d and -e. 

/var is on da0e, /tmp is on da0f and /usr is on da0g. I do apologize, that was ambiguous. 
It's in the readme for that revision number now.

> 
> 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.
> 
Yes, this is the same pair of devices which produced the flood of USB errors
when either deliberately run out of swap or used with OOMA turned off. The
USB flash drive is a Sandisk SDCZ800-064G, nominally a "USB3.1" device. It's
quite clear that I/O congestion badly affects performance, but I'm not convinced
it's exclusively swap I/O that causes trouble. Sometimes it looks as if traffic
to /usr gums up the works and takes minutes  to unjam. 

In any case, the fact that the system rights itself and keeps working is encouraging.
It's also interesting, though probably not useful, to note that 4 GB of swap seems
to cause no trouble, at least in this configuration. I haven't tried 6 GB yet.

Thanks for reading,

bob prohaska




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