Date: Tue, 01 Oct 2024 15:40:26 +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-r2QxXrDu90@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 #14 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Henrich Hartzer from comment #13) As for memory not vanishing after the kldunload of zfs.ko . . . But your earlier reported: Mem: 1536M Active, 1590M Inact, 306M Laundry, 1371M Wired, 603M Buf, 221M F= ree was still missing a lot of memory (skipping Buf): The 1536+1590+306+1371+221 =3D=3D 5024 was well less than the "7787 MB" of "avail memory". Rebooting such that zfs.ko is never loaded may well get nearer to the 7787 MB for the total and stay that way. (Still could be change categories going away from Free so that Free decreases over time.) For "failed to reclaim memory" there is a tunable that can delay the process kills: runs longer with the low Free RAM figure. There are a couple of others that could well be appropriate to that context. However, for now, Mark J. likely is more interested in the decreasing total that happened with zfs.ko loaded but was partially undone by the kldunload. This is more unsual than just having the "failed to reclaim memory" issue with FireFox in use. --=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-r2QxXrDu90>