Date: Sat, 4 Aug 2018 06:40:15 -0700 From: John Kennedy <warlock@phouka.net> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] Message-ID: <20180804134015.GA30738@phouka1.phouka.net> In-Reply-To: <8CC5DF53-F950-495C-9DC8-56FCA0087259@yahoo.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180804134015.GA30738>