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

John Kennedy warlock at phouka.net
Sat Aug 4 13:41:39 UTC 2018


On Sat, Aug 04, 2018 at 12:14:52AM -0700, Mark Millard via freebsd-arm wrote:
> ... 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.) ...

For what it's worth, when I was first getting my rpi3 up and running, tuning
swap and rebuilding world+kernel it really seemed to favor killing off ntpd
and then usually a cc during the build (which resulted in a recoverable fail
as I had to restart the build process with NO_CLEAN=yes.

This was using 12-current kernels.  Bumping /tmp (tmpfs) up to 75M (from 50)
and having a proper freebsd-swap (vs swap-on-UFS-file) (and perhaps a V30 SD
card) fixed all of that.  I still have to set TMPDIR=/var/tmp (disk, not
tmpfs) during installworld beacuse it tries to strip at least one really big
executable during the install and that'll break with <= 75M of /tmp.


More information about the freebsd-arm mailing list