RPI3 swap experiments, was Re: GPT vs MBR for swap devices
bob prohaska
fbsd at www.zefox.net
Tue Jun 26 05:24:44 UTC 2018
On Sun, Jun 24, 2018 at 09:22:38PM -0700, Mark Millard wrote:
> On 2018-Jun-24, at 4:10 PM, bob prohaska <fbsd at www.zefox.net> wrote:
>
>
> > I've tried to replicate the RPi3 "run out of swap" experiment after
> > updating source, kernel and world to r335576. Roughly the same things happen:
> > Errors flood the console, when swap usage goes a bit over 80% the machine becomes
> > unresponsive. No sign of the OOM assassin.
> >
> > However, -j4 buildworld got all the way to building libraries. With r334939 it
> > always stopped in cross tools. That seems like a significant improvement
> > in swap usage efficiency. Is this to be expected?
> >
>
> >From the log file:
>
> http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/buildworld.log
>
> is the text:
>
> --- buildworld ---
> make[1]: "/usr/src/Makefile.inc1" line 299: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler.
> make[1]: "/usr/src/Makefile.inc1" line 304: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker.
>
> So the cross compiler and cross linker were not built: the existing
> llvm files were used.
>
Ahh, so it wasn't a massive performance increase.... too bad!
>
> > What details were captured can be seen at
> > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/
> > in case they're of interest.
>
>
> You are still using the drive that gets the errors ( /dev/da0 ),
> even if it is not being used for swapping.
>
> http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/console
>
> shows:
>
> _vfs_done():da0d[WRITE(offset=51819347968, length=131072)]error = 5
> g_vfs_done():da0d[WRITE(offset=51819479040, length=28672)]error = 5
> g_vfs_done():da0d[READ(offset=59586936832, length=32768)]error = 5
> g_vfs_done():vm_fault: pager read error, pid 823 (tcsh)
Yes, I'm still using that same device. The errors attributed to /dev/da0
were reported nearly two hours after the system first reported distress.
That makes it hard to believe the errors caused the problem.
It's easier to see in a re-run of the same experiment, with the last two
lines of /var/log/messages tacked on to the gstat and swapinfo log.
The file can be found in
http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/1gbsdflash/2ndtest/
along with a pair of files sorted by read and write delay and a copy-paste
of the top window after the power was cycled.
The errors quoted above seem to
start around timestamp Jun 25 19:54:28, but the system is clearly in trouble
at timestamp Jun 25 17:58:55. OOMA never takes visible action which seems
strange given the explicit getswapspace failures.
Following timestamp Mon Jun 25 19:52:33 the log file becomes somewhat garbled.
In looking through the log files of successful buildworlds there seem to be a
random sprinkling of huge (~20 second) read and write delays, often clearing
themselves in one or two 10-second sampling intervals. While they're certainly
not good they weren't fatal.
Thanks for reading,
bob prohaska
More information about the freebsd-arm
mailing list