Date: Sun, 12 Aug 2018 16:23:31 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net>, Mark Johnston <markj@FreeBSD.org> Cc: John Kennedy <warlock@phouka.net>, freebsd-arm <freebsd-arm@freebsd.org>, fbssd@www.zefox.net Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <B81E53A9-459E-4489-883B-24175B87D049@yahoo.com> In-Reply-To: <20180812224021.GA46372@www.zefox.net> References: <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <EC74A5A6-0DF4-48EB-88DA-543FD70FEA07@yahoo.com> <20180806155837.GA6277@raichu> <20180808153800.GF26133@www.zefox.net> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Aug-12, at 3:40 PM, bob prohaska <fbsd at www.zefox.net> wrote: > On Sun, Aug 12, 2018 at 10:32:48AM -0700, John Kennedy wrote: >> . . . > Setting vm.pageout_oom_seq to 120 made a decisive improvement, almost = allowing > buildworld to finish. By the time I tried CAM_IOSCHED_DYNAMIC = buildworld was > getting only about half as far, so it seems the patches were harmful = to a degree. > Changes were applied in the order=20 You could experiment with figures bigger than 120 for vm.pageout_oom_seq . I'll note that the creation of this mechanism seems to be shown for -r290920 at: = https://lists.freebsd.org/pipermail/svn-src-head/2015-November/078968.html= In part is says: . . . only raise OOM when pagedaemon is unable to produce a free page in several back-to-back passes. Track the failed passes per pagedaemon thread. =20 The number of passes to trigger OOM was selected empirically and tested both on small (32M-64M i386 VM) and large (32G amd64) configurations. If the specifics of the load require tuning, sysctl vm.pageout_oom_seq sets the number of back-to-back passes which must fail before OOM is raised. Each pass takes 1/2 of seconds. Less the value, more sensible the pagedaemon is to the page shortage. The code shows: int vmd_oom_seq and it looks like fairly large values would be tolerated. You may be able to scale beyond the problem showing up in your context. > pageout=20 > batchqueue > slow_swap > iosched For my new Pine64+ 2GB experiments I've only applied the Mark J. reporting patches, not the #define one. Nor have I involved CAM_IOSCHED_DYNAMIC. But with 2 GiBytes of RAM and the default 12 for vm.pageout_oom_seq I got: v_free_count: 7773, v_inactive_count: 1 Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out = of swap space with no other reports from Mark Johnston's reporting patches. It appears that long I/O latencies as seen by the subsystem are not necessary to ending up with OOM kills, even if they can contribute when they occur. (7773 * 4 KiBytes =3D 31,838,298 Bytes, by the way.) > My RPI3 is now updating to 337688 with no patches/config changes. I'll = start the > sequence over and would be grateful if anybody could suggest a better = sequence. Side note: more text from -r290920 : In future, some heuristic to calculate the value of the tunable might be designed based on the system configuration and load. But before it can be done, the i/o system must be fixed to reliably time-out pagedaemon writes, even if waiting for the memory to proceed. Then, code can account for the in-flight page-outs and postpone OOM until all of them finished, which should reduce the need in tuning. Right now, ignoring the in-flight writes and the counter allows to break deadlocks due to write path doing sleepable memory allocations. I've no clue if this ever progressed after -r290920 . =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?B81E53A9-459E-4489-883B-24175B87D049>