Date: Tue, 22 Oct 2024 18:01:03 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page Message-ID: <bug-280846-227-j86Nxv3Dm8@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-280846-227@https.bugs.freebsd.org/bugzilla/> References: <bug-280846-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280846 --- Comment #53 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Henrich Hartzer from comment #50) "failed to reclaim memory" is from multiple attempts to increase the free RAM to not be below a target threshold. There is a parameter for controlling the number of attempts before the related OOM kills start. For example in /boot/loader.conf I have: # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 (You might well want bigger than 120. The default is 12 --last I knew anyway. You might want 1200 or 12000 for experimenting. I expect too large a number might end up with overflow problems but have not checked the details.) The setting does not ever disable the "failed to reclaim memory" OOM activity. It just makes it take longer to happen. It is more useful for spanning temporary heavy RAM use, such as can happen during buildworld, for example. It is not a fix for permanent heavy RAM use. But it can help allow exploring a context by giving more time before the OOM activity happens. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-280846-227-j86Nxv3Dm8>