RPI3 swap experiments
fbsd at www.zefox.net
Thu Jun 28 02:24:44 UTC 2018
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
> 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!
More information about the freebsd-arm