Date: Sat, 12 Apr 2025 18:41:07 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD ARM List <freebsd-arm@freebsd.org> Subject: FYI: aarch64 FreeBSD under Parallels on macOS: how to avoid paging OOMs for "was killed: a thread waited too long to allocate a page" Message-ID: <114C309C-06F6-48E4-ABE1-C2CD4C617450@yahoo.com> References: <114C309C-06F6-48E4-ABE1-C2CD4C617450.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I've been doing more poudriere-devel based "bulk -a" experiments (with pkg 2.1.0 involved) and was still getting "was killed: a thread waited too long to allocate a page". I made an adjustment to the Parallels configuration that I've been using and, so far, the paging OOM's have stopped --even when I pushed the paging harder than I had been before the change. The adjustment doing this may depend on the RAM allocation used. Context: M4 MAX with 16 cores: 12 Performance and 4 Efficiency. Also: The M4 MAX has 128 GiBytes of RAM. I previously had 14 virtual/FreeBSD cpus. I changed that to 12, matching the Performance core count. This might have helped in one or both of a couple of ways of note: ) FreeBSD was no longer competing for Efficiency Core use. (Parallels automatically uses just Performance cores when the count is small enough.) ) Same amount of RAM allocated to FreeBSD as before --but for fewer FreeBSD cpus: less memory pressure internal to FreeBSD. I will note that I've observed as high as 15035 MiBytes of Swap Space in use. Not necessarily at that same time: 76729 MiByte for: Active+Wired+Laundry+SwapUsed and at that time: 76740 MiByte for: Active+Wired+Laundry+SwapUsed+InAct (so: not much InAct at the time) (Monitored with personal top patches.) The style of "bulk -a" use allows large load averages relative to the FreeBSD cpu count, such as the maximums for the 3 having observed values (each with its own time frame) 57.68, 44.03, 39.85 when there are 12 FreeBSD cpus. For reference for the RAM allocated to FreeBSD: I allocate 64 GiBytes of RAM to the FreeBSD VM. Its intent is that, for my context of use, this leaves macOS with over 32 GiBytes of RAM free when parallels has allocated the whole 64 GiBytes for the FreeBSD: more like 36 GiBytes free as it turns out. That, in turn, avoids macOS doing things like compressing memory to get back Free Space. (That seems to start at around 28 GiBytes or less free on macOS, if I remember what I observed right. I have margin for handling variability.) === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?114C309C-06F6-48E4-ABE1-C2CD4C617450>