From owner-freebsd-arm@freebsd.org Mon Aug 13 20:15:56 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4827C107C5EF for ; Mon, 13 Aug 2018 20:15:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-9.consmr.mail.gq1.yahoo.com (sonic308-9.consmr.mail.gq1.yahoo.com [98.137.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C267C8AFAC for ; Mon, 13 Aug 2018 20:15:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 6IAKzPsVM1mmaoEtxCMk2.KzVZHtfAd1fNupIiHqEgnn.SdICsLikgO9HltgKfa gIbLnpXuafGsmBploO.m8ElvcNV_judvz7g_grkIWku1Wz2_bdRih_a.dhQS4LUlFuirBEmTWLpT pYb7rHYczruVCq2QZaijJDKPGjhkeiOonNjHlg9HIIOGUZYuKHYr2voGtGVWpUytN.cYKm_DEN6a tTYViKSRu8FwBiEKB2yIes916sSiGgZ.sRE4MKxrC1fAxD6JhfidacC5ugSgx3VH1LjHIeujftyq dGB_e1yoOMRDrYnBfUTBJ4FBLzeblJD9WGMzcc.n88r37uGBEkJEXDxyL.omvRGgG1.wW0uvHdo6 DMZgaP2z15j3_dmDaN.Got54KIJiR2iHsd.vEJsvMNfHIedCaM.4W8KIhkEDzf7p89hjm0Iz0T86 tTA8mdjJBnalG4F7gvgz5bgRgeMSxBkZb4imnUArA5GM3uoN_QpYuKouAZ7qKQ8OMK_m0eEITvDx AZ4uVO6Yl8UvTaEnTZJd6JiCFJBFAuJWU6NasG2IdGMqdb4I18WnbP_hGJd0KDsnjDup7NfZ7sem Wn2LEcwa7_N2J7XDFmG29dQBRjSJCYVwFqpndvHOf_1laoKIzz5Y6k88Ew1h6LFLWxA4fNygqjzc fHL9iSDizik6Ua_An1f4kXLxylBPiUNYT.CTQh9aqFqNbwkpDVqQxA3p9pHBX5j74uZvpvsfwekD 5CeX06F5hWd7h8M_zCTfXqoHQNcjcp9nXWSuRUYPK2zmnyirJt.iFAWpCCUhQu52OOmAaH0A_G8a M54c6U91nKoH.JPOVD6IfKFHu_nj8ePjpSTChrFL_.jO8Og9BU8qcJwPPZ5VisLpDAs7Q_Ny7Fnw IsE8_Sju3VqoCJrHEIY80U3O55jsLwRxOVzLuBfSPN3GoN7PQN4dd.Ty2Hf.awSSLpiww4bgxojN CpylgXpra_6vCSqHna7qh79BYbkt9a4PHgs7JI4P3dPyotYbl_A5pQSafB9TUI4Y7QIfjCL1oplu rsiFYsUL2jHA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 13 Aug 2018 20:15:48 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1f8ea332bef4cf0752c370d22f4df331; Mon, 13 Aug 2018 20:05:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <20180813185350.GA47132@www.zefox.net> Date: Mon, 13 Aug 2018 13:05:38 -0700 Cc: Mark Johnston , John Kennedy , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: 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> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180813185350.GA47132@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 20:15:56 -0000 On 2018-Aug-13, at 11:53 AM, bob prohaska wrote: > On Mon, Aug 13, 2018 at 10:35:38AM -0700, Mark Millard wrote: >> On 2018-Aug-12, at 8:36 PM, Mark Millard = wrote: >>=20 >>> On 2018-Aug-12, at 7:12 PM, bob prohaska = 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)