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 
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