Date: Sat, 4 Aug 2018 09:08:48 -0700 From: Mark Millard <marklmi@yahoo.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: Jamie Landeg-Jones <jamie@catflap.org>, bob prohaska <fbsd@www.zefox.net>, freebsd-arm <freebsd-arm@freebsd.org>, markj@freebsd.org Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <16ABD9F0-C908-479C-960D-0C1AEDE89053@yahoo.com> In-Reply-To: <20180804140816.GJ2884@funkthat.com> References: <20180801034511.GA96616@www.zefox.net> <201808010405.w7145RS6086730@donotpassgo.dyslexicfish.net> <6BFE7B77-A0E2-4FAF-9C68-81951D2F6627@yahoo.com> <20180802002841.GB99523@www.zefox.net> <20180802015135.GC99523@www.zefox.net> <EC74A5A6-0DF4-48EB-88DA-543FD70FEA07@yahoo.com> <201808030034.w730YURL034270@donotpassgo.dyslexicfish.net> <F788BDD8-80DC-441A-AA3E-2745F50C3B56@yahoo.com> <201808040355.w743tPsF039729@donotpassgo.dyslexicfish.net> <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.com> <20180804140816.GJ2884@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Aug-4, at 7:08 AM, John-Mark Gurney <jmg at funkthat.com> wrote: > Mark Millard via freebsd-arm wrote this message on Sat, Aug 04, 2018 = at 00:14 -0700: >> On 2018-Aug-3, at 8:55 PM, Jamie Landeg-Jones <jamie at catflap.org> = wrote: >>=20 >>> Mark Millard <marklmi at yahoo.com> wrote: >>>=20 >>>> If Inact+Laundry+Buf(?)+Free was not enough to provide sufficient >>>> additional RAM, I'd would have guessed that some Active Real Memory >>>> should then have been paged/swapped out and so RAM would be made >>>> available. (This requires the system to have left itself sufficient >>>> room in RAM for that guessed activity.) >>>>=20 >>>> But I'm no expert at the intent or actual operation. >>>>=20 >>>> Bob P.'s reports (for having sufficient swap space) >>>> also indicate the likes of: >>>>=20 >>>> v_free_count: 5439, v_inactive_count: 1 >>>>=20 >>>>=20 >>>> So all the examples have: "v_inactive_count: 1". >>>> (So: vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt=3D=3D1 ) >>>=20 >>> Thanks for the feedback. I'll do a few more runs and other stress = tests >>> to see if that result is consistent. I'm open to any other idea too! >>>=20 >>=20 >> The book "The Design and Implementation of the FreeBSD Operating = System" >> (2nd edition, 2014) states (page labeled 296): >>=20 >> QUOTE: >> The FreeBSD swap-out daemon will not select a runnable processes to = swap >> out. So, if the set of runnable processes do not fit in memory, the >> machine will effectively deadlock. Current machines have enough = memory >> that this condition usually does not arise. If it does, FreeBSD = avoids >> deadlock by killing the largest process. If the condition begins to = arise >> in normal operation, the 4.4BSD algorithm will need to be restored. >> END QUOTE. >>=20 >> As near as I can tell, for the likes of rpi3's and rpi2's, the = condition >> is occurring during buildworld "normal operation" that tries to use = the >> available cores to advantage. (Your context does not have the I/O >> problems that Bob P.'s have had in at least some of your OOM process >> kill examples, if I understand right.) >>=20 >> (4.4BSD used to swap out the runnable process that had been resident >> the longest, followed by the processes taking turns being swapped = out. >> I'll not quote the exact text about such.) >>=20 >> So I guess the question becomes, is there a reasonable way to enable >> the 4.4BSD style of "Swapping" for "small" memory machines in order = to >> avoid having to figure out how to not end up with OOM process kills >> while also not just wasting cores by using -j1 for buildworld? >>=20 >> In other words: enable swapping out active RAM when it eats nearly >> all the non-wired RAM. >>=20 >> But it might be discovered that the performance is not better than >> using fewer cores during buildworld. (Experiments needed and >> possibly environment specific for the tradeoffs.) Avoiding having >> to figure out the maximum -j? that avoids OOM process kills but >> avoids just sticking to -j1 seems and advantage for some rpi3 and >> rpi2 folks. >=20 > Interesting observation, maybe playing w/: > vm.swap_idle_threshold2: Time before a process will be swapped out > vm.swap_idle_threshold1: Guaranteed swapped in time for a process >=20 > will help thing... lowering 2 will likely make the processes = available > for swap sooner... Looking up related information: https://www.freebsd.org/doc/handbook/configtuning-disk.html says vm.swap_idle_enabled is also involved with those two. In fact it indicates the two are not even used until vm.swap_idle_enabled=3D1 . QUOTE 11.10.1.4. vm.swap_idle_enabled The vm.swap_idle_enabled sysctl(8) variable is useful in large = multi-user systems with many active login users and lots of idle = processes. Such systems tend to generate continuous pressure on free = memory reserves. Turning this feature on and tweaking the swapout = hysteresis (in idle seconds) via vm.swap_idle_threshold1 and = vm.swap_idle_threshold2 depresses the priority of memory pages = associated with idle processes more quickly then the normal pageout = algorithm. This gives a helping hand to the pageout daemon. Only turn = this option on if needed, because the tradeoff is essentially pre-page = memory sooner rather than later which eats more swap and disk bandwidth. = In a small system this option will have a determinable effect, but in a = large system that is already doing moderate paging, this option allows = the VM system to stage whole processes into and out of memory easily. END QUOTE The defaults seem to be: # sysctl vm.swap_idle_enabled vm.swap_idle_threshold1 = vm.swap_idle_threshold2 vm.swap_idle_enabled: 0 vm.swap_idle_threshold1: 2 vm.swap_idle_threshold2: 10 Quoting the book again: QUOTE If the swapping of idle processes is enabled and the pageout daemon can = find any processes that have been sleeping for more than 10 seconds = (swap_idle_threshold2, the cutoff for considering the time sleeping to be "a long time"), it = will swap them all out. [. . .] if none of these processes are available, the = pageout daemon will swap out all processes that has been sleeping for as briefly = as 2 seconds (swap_idle_threshold1). END QUOTE. I'd not normally expect a compile or link to sleep for such long periods (unless I/O has long delays). Having, say, 4 such processes active at = the same time may be unlikely to have any of them swap out on the default = scale. (Clang is less I/O bound and more memory bound than GCC as I remember = what I've observed. That statement ignores paging/swapping by the system.) Such would likely be true on the scale of any positive integer seconds figures? =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?16ABD9F0-C908-479C-960D-0C1AEDE89053>