Date: Mon, 13 Aug 2018 13:05:38 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Mark Johnston <markj@FreeBSD.org>, John Kennedy <warlock@phouka.net>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <FA3B8541-73E0-4796-B2AB-D55CE40B9654@yahoo.com> In-Reply-To: <20180813185350.GA47132@www.zefox.net> References: <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <B81E53A9-459E-4489-883B-24175B87D049@yahoo.com> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <FC0798A1-C805-4096-9EB1-15E3F854F729@yahoo.com> <20180813185350.GA47132@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Aug-13, at 11:53 AM, bob prohaska <fbsd@www.zefox.net> wrote: > On Mon, Aug 13, 2018 at 10:35:38AM -0700, Mark Millard wrote: >> On 2018-Aug-12, at 8:36 PM, Mark Millard <marklmi at yahoo.com> = wrote: >>=20 >>> On 2018-Aug-12, at 7:12 PM, bob prohaska <fbsd at www.zefox.net> = wrote: >>>=20 >>>> . . . >>>> Would 1024 be enough to turn OOMA off completely? That's what I = originally wanted to=20 >>>> try. >>>=20 >>=20 >> [The 1024 is for vm.pageout_oom_seq.] >>=20 >> I'm going to try a different wording about vm.pageout_oom_seq >> to address such questions: >>=20 >> vm.pageout_oom_seq indirectly sets how long FreeBSD will tolerate >> Low Free RAM (by its Low Free RAM criteria). The "indirect" is >> because my wording is time based but the vm.pageout_oom_seq units >> are not. For a given environment smaller vs. larger is less time >> vs. more time. >>=20 >> So, while one can make FreeBSD tolerate Low Free RAM longer >> (up to a point, apparently huge), no specific value directly >> turns off OOM (better: Low Free RAM) process killing. (Based on >> mathematical arithmetic. I've not analyze odd consequences of >> causing overflows for the code's details.) >>=20 >> The approximation to turning off being intolerant of Low Free >> RAM is to have vm.pageout_oom_seq so large that you would not >> be willing to wait for the process kills to start. >>=20 >> But the minimum for that is likely not obvious, so just use >> a fairly large figure for the int value for the architecture >> being tested. (rpi2 V1.1's and rpi3's have fairly large int >> types in C.) >>=20 >> (I've assumed that the representation of vm.pageout_oom_seq is >> respected everywhere that it is used. If someplace mixes it >> with smaller types, this would need to be considered for what >> is "fairly large". This would require a code inspection.) >>=20 >=20 > I'll start with 1024 as "almost" ten times 120 and see what happens. >=20 > Thank you very much for explaining in plain English what=20 > vm.pageout_oom_seq influences. I had no idea it was tied=20 > to free RAM, taking the reference to swap literally.=20 The "out of swap space" in: Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out = of swap space is just wrong relative to what drives the killing. The swap space may or may not be low, that depends on the overall set/number of processes and their properties. This whole investigation would have been better directed up front by different text in the message. > I can't resist asking two dumb questions: > First, why the confusing wording of the error message, is it shared = with other tests? The wording might go back to 4.4BSD when swapping of running processes was done and the kills likely did not happen until such swapping became unavailable via swap space limitations for the configuration. For FreeBSD it is very misleading to anyone not already familiar with FreeBSD's choices in this area. (That would be me before finding the material that I quoted from the book.) > Second, wouldn't it be better to suppress the starting of new = processes, rather than > killing those already underway? Sort of like a harried clerk saying = "take a number!". Nothing says that attempts to create new processes are going on in all workloads with the issue. And if Free RAM is already low, it would stay low. Just one process that keeps a sufficient number of pages in the "Active" category for an environment and stays runnable all the time can lead to kills of processes that are not subject to being swapped out. > Another approach might be to write an entire process space to /tmp for = restart when the > crisis is over. Lousy for throughput, but it would keep folks away = from the power switch. Sounds like you just specified a form of swapping, /tmp not being fundamental. In other words: more like 4.4BSD style, not FreeBSD style. Here there is architecture choice and goals/primary contexts. FreeBSD is never likely to primarily target anything with a workload like buildworld buildkernel on hardware like rpi3's and rpi2 V1.1's and Pine64+ 2GB's and so on. And if things were still like gcc 4.2.1 for what it takes to build the toolchain, this likely would not have been noticed on such hardware. The big change has been what it takes to build the toolchain instance(s) that other stages of buildworld buildkernel use. That is the change in the workload that requires changes in the likes of vm.pageout_oom_seq for buildworld buildkernel --or just finding a -jN figure that avoids leading to Low Free RAM for the environment(when possible). =3D=3D=3D 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?FA3B8541-73E0-4796-B2AB-D55CE40B9654>