Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Sep 2018 23:20:14 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        bob prohaska <fbsd@www.zefox.net>
Cc:        "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, freebsd-arm@freebsd.org
Subject:   Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap)
Message-ID:  <AA5BA4D3-5C06-4E18-B7D3-C8A5D0272F43@yahoo.com>
In-Reply-To: <20180906042353.GA3482@www.zefox.net>
References:  <20180906003829.GC818@www.zefox.net> <201809060243.w862hq7o058504@pdx.rh.CN85.dnsmgr.net> <20180906042353.GA3482@www.zefox.net>

next in thread | previous in thread | raw e-mail | index | archive | help


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)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA5BA4D3-5C06-4E18-B7D3-C8A5D0272F43>