RPI3 swap experiments

Mark Millard marklmi at yahoo.com
Tue Jul 31 06:44:46 UTC 2018



On 2018-Jul-30, at 10:47 PM, bob prohaska <fbsd at www.zefox.net> wrote:

> OOMA is still killing processes in -j4 buildworld sessions for no obvious reason
> when using mixed USB/microSD swap.  The most recent experiment is with r336877 
> rebuilding itself from a clean start.
> 
> The various log files are at 
> http://www.zefox.net/~fbsd/rpi3/swaptests/r336877/
> The OOMA kills occur around two hours after
> the worst read/write delays, which are in the low tens
> of seconds. Perhaps most curiously, the long delays
> don't appear to involve swap partitions. 
> 
> 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.

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


> 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 no expert at such so if someone that knows makes a claim,
believe them instead of me.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)



More information about the freebsd-arm mailing list