RPI3 swap experiments

[bob prohaska]

On Wed, Jun 27, 2018 at 06:12:53PM -0700, Mark Millard wrote:
> On 2018-Jun-27, at 12:42 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> 
> > On Tue, Jun 26, 2018 at 11:30:52PM -0700, Mark Millard wrote:
> >> On 2018-Jun-26, at 10:40 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> >> 
> >> . . .
> >> For (A), have you tried any examples of:
> >> 
> >> sufficient swap on mmcsd0 (or other such) with no swap
> >> on da0 (but /usr and /var on /dev/da0)?
> > Yes, that is the configuration which completes successfully.
> >> 
> >> If yes, did you check on if there were /dev/da0 errors
> >> logged? What, if any, /dev/da0 errors where logged?
> >> None?
> > Correct, no errors on da0 when -j4 buildworld is successful.
> 
> Good to know. Thanks.
> 
> >> For (B), have you tried any examples of:
> >> 
> >> insufficient swap on (say) mmcsd0 and no use of the
> >> /dev/da0 drive that has reported errors at all,
> >> /usr/ and /var not on mmcsd0 (or whatever was used
> >> for swap) either? Did some drive end up reporting
> >> errors? Which? Did the system still crash as well?
> >> 
> > I think this is the standard test case:
> > /usr and /var on /dev/da0
> > /tmp on /dev/mmcsd0s3a
> > swap on /dev/mmcsd0s3b
> > 
> > This configuration has crashed reliably with errors on /dev/da0 but no other "disk" errors.
> > Did I understand the question correctly?
> 
> I intended for "no use of /dev/da0" to indicate
> that not even /usr or /var were from the device
> that has been logging the errors. For example:
> having /usr or /var on the mechanical disk and
> the known-problem disk not connected at all.
> 
Not yet, but absent new developments I'm running out of
other things to try. My hesitations stems partly from my
own sloth, but mostly from a concern that I'll introduce
confounding changes unintentionally. I'm hopeful Jaimie
will get his Pi3 running and see something interesting.

Some time ago I asked whether it would be better to
dd the existing da0 onto another device or better to
construct a complete new installation (new snapshot
on a new microSD plus a new USB thumb drive). Would
you venture a guess?
 
> This would get either no-errors or some other
> device would get errors, possibly the mechanical
> disk (if that was the type used for a test).
> 
> >> 
> >> 
> >> Have such test-context combinations been tried?
> >> 
> >> Without any logs to look at for such alternatives, I
> >> can not try to compare/contrast such to the others
> >> examples.
> >> 
> > 
> > Understood. The matrix of test conditions is not completely filled,
> > and the test of different media for /dev/da0 has not yet been made.
> > I'd like to play with stress2 and ports/sysutils/stress before doing
> > that.
> 
> It would be handy for something simpler than buildworld to be
> able to induce some of the types of problems, for sure.
> 
It's difficult to gather persuasive test statistics at one trial per day 8-)

> > There is a new, successful -j4 buildworld swapuse.log for the case
> > of 3 GB of USB flash swap at
> > 
> > http://www.zefox.net/~fbsd/rpi3/swaptests/r335576/3gbusbflash/
> > 
> 
> I do not see a console.log or notes about the console messages
> (or lack of such). Where there any messages there of note? No
> device errors? Was such checked for?
>
Nothing on the console apart from normal remote-login failures.
The gstat data shows widely-scattered large delays, but they're
brief and don't seem to cause trouble. 
 
> > The system is now up to r335655 and I'm trying to replicate 
> > earlier crash behavior before proceeding further. 
> > 
> 
> Sounds good.
> 
> I will note that the following might help memory handling
> for your context (small memory context):
> 
> Author: alc
> Date: Tue Jun 26 18:29:56 2018
> New Revision: 335674
> URL: https://svnweb.freebsd.org/changeset/base/335674
> 
> Log:
>   Update the physical page selection strategy used by vm_page_import() so
>   that it does not cause rapid fragmentation of the free physical memory.
>   
>   Reviewed by:	jeff, markj (an earlier version)
>   Differential Revision:	https://reviews.freebsd.org/D15976
> 
It's encouraging that folks are making some progress. 

Thanks for reading!

bob prohaska