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>