RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"]

[Mark Millard]

[I think the messages produced for OOM kills are misleading for
the type of context in this message exchange. More bottom-posted.]

On 2018-Aug-4, at 6:45 PM, John-Mark Gurney <jmg at funkthat.com> wrote:

Mark Millard wrote this message on Sat, Aug 04, 2018 at 09:08 -0700:
> 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:
>>>>  . . .
>>> 
>>> The book "The Design and Implementation of the FreeBSD Operating System"
>>> (2nd edition, 2014) states (page labeled 296):
>>> 
>>> 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.
>>> 
>>> 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.)
>>> 
>>> (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.)
>>> 
>>> 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?
>>> 
>>> In other words: enable swapping out active RAM when it eats nearly
>>> all the non-wired RAM.
>>> 
>>> 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.

The book's description makes the messages produced misleading:
(copied from someone else's message)

	Aug  5 01:34:24 rpi3 kernel: pid 63223 (ld.lld), uid 0, was killed: out of swap space
	Aug  5 01:34:26 rpi3 kernel: pid 63360 (c++), uid 0, was killed: out of swap space
	Aug  5 01:34:26 rpi3 kernel: pid 846 (ntpd), uid 123, was killed: out of swap space

"out of swap space" would appear to apply to the 4.4BSD style of swapping but
not necessarily to more modern FreeBSD's context.

"Total Active Working Set too large" (with lots of swap left) seems to be what folks
are running into in these rpi3/rpi2 examples.

If the messages had indicated such, this message chain would likely have been
rather different: working out adjustments of the total active working set size.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)