RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap)

[Mark Millard]

On 2018-Sep-5, at 9:23 PM, bob prohaska <fbsd at www.zefox.net> wrote:

> On Wed, Sep 05, 2018 at 07:43:52PM -0700, Rodney W. Grimes wrote:
>> 
>> What makes you believe that the VM system has any concept about
>> the speed of swap devices?  IIRC it simply uses them in a round
>> robbin fashion with no knowlege of them being fast or slow, or
>> shared with files systems or other stuff.
>> 
> 
> Mostly the assertion that OOMA kills happening when the system had
> plenty of free swap were caused by the swap being "too slow". If the
> machine knows some swap is slow, it seems capable of discerning other
> swap is faster. 

If an RPI3 magically had a full-speed/low-latency optane context
as its swap space, it would still get process kills for buildworld
buildkernel for vm.pageout_oom_seq=12 for -j4 as I understand
things at this point. (Presumes still having 1 GiByte of RAM.)

In other words: the long latency issues you have in your rpi3
configuration may contribute to the detailed "just when did it
fail" but low-latency/high-speed I/O would be unlikely to prevent
kills from eventually happening during the llvm parts of buildworld .
Free RAM would still be low for "long periods". Increasing
vm.pageout_oom_seq is essential from what I can tell.

vm.pageout_oom_seq is about controlling "how long". -j1 builds are
about keeping less RAM active. (That is also the intent for use of
LDFLAGS.lld+=-Wl,--no-threads .) Of course, for the workload involved,
using a context with more RAM can avoid having "low RAM" for
as long. An aarch64 board with 4 GiBYte of RAM and 4 cores possibly
has no problem for -j4 buildworld buildkernel for head at this
point: Free RAM might well never be low during such a build in such
a context.

(The quotes like "how long" are because I refer to the time
consequences, the units are not time but I'm avoiding the detail.)

The killing criteria do not directly measure and test swapping I/O
latencies or other such as far as I know. Such things are only
involved indirectly via other consequences of the delays involved
(when they are involved at all). That is my understanding.



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