RPI3 swap experiments

[bob prohaska]

On Tue, Jul 31, 2018 at 12:02:12AM -0700, Mark Millard wrote:
> On 2018-Jul-30, at 11:44 PM, Mark Millard <marklmi at yahoo.com> wrote:
> 
> > On 2018-Jul-30, at 10:47 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> > 
> >> Similar problems now seem present with the RPI2 on
> >> 11-stable. The first failure was with r335398 trying 
> >> to compile 336871. Buildworld has been backed down to 
> >> -j2 and restarted in the hope it'll eventually succeed.
> >> In this particular case all swap is on USB, in a single
> >> 2 GB partition.
> > 
> > My records indicate (from old boot messages and reported
> > in past list messages):
> > 
> > rpi2: . . . exceeds maximum recommended amount (411488 pages).
> > rpi3: . . . exceeds maximum recommended amount (925680 pages).
> > 
> > 411488*4K Bytes = 1,685,454,848 Bytes for rpi2 (older V1.1 armv7
> > variant). In other words: you have more swap than is recommended
> > for such a context because of fragmentation issues and such for
> > overhead information related to keeping track of swapping/paging.
> >

What disturbs me is that the 11-stable machine was in the past able
to run a -j4 buildworld successfully. Seemingly it's becomeing
less robust, not more. That's a bad sort of progress 8-)
 
> > I suggest trying not exceeding the 1,685,454,848 figure for the
> > rpi2 context, just as a cross check. May be 411000*4K Bytes,
> > so 1,683,456,000 Bytes, avoiding being right at the boundary?
> > 
> > 925680*4K Bytes = 3,791,585,280 Bytes for rpi3.
> > 
> > Are thew drives involved different ones than used with the
> > rpi3 experiments? (Just curious.)
> > 

No, they're different machines entirely. 

> > 
> >> It would be most interesting to see what happens if OOMA
> >> could be turned off. Is that possible? 
> > 
> > If the code reaches conditions which initiate OOMA now, what
> > would proposed alternate action be? As stands if OOMA itself
> > fails to happen, my guess would be the kernel would panic,
> > deadlock, or livelock in some way. Simply having OOMA not
> > attempted would likely be the same as OOMA failing unless
> > more than disabling OOMA was done.
> >

I'm simply curious to see if the buildworld completes successfully
or not, in the absence of OOMA intervention. The insistence has been
that OOMA is triggered by excessive delays in accessing storage devices.
However, it looks as if OOMA kills aren't correlated in time with
storage read/write delays and do seem to be correlated to swap layout,
being worse when swap is distributed across both USB and microSD. 

There were similar reports of wanton process killing on other platforms,
but I haven't seen one in several weeks at least. Was that problem 
identified and solved, or has it simply faded into old news?

Thanks for reading!

bob prohaska