Date: Mon, 12 Oct 2020 06:42:15 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 250226] graphics/drm-fbsd12.0-kmod: massive memory leak Message-ID: <bug-250226-7141-zSk9Dv1pFi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-250226-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-250226-7141@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=3D250226 Scott Bennett <bennett@sdf.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bennett@sdf.org --- Comment #1 from Scott Bennett <bennett@sdf.org> --- Your description matches that of a collection of bugs present in 11.2 = to 11.4 and 12.x that others began complaining of on other lists within days of the release of 11.2. I have complained on the x11 and stable lists about them a few times this year because they are still a problem and because the FreeBSD developers have not addressed them. Over time others have found a number of sysctl workarounds, and I have found a few others and have accumulated seve= ral that, in combination, allow me to keep my system usable for weeks at a time, rather than a day to three or four days. They do not fix the bugs, however. One glaring bug is that vm.max_wired is now ignored by the kernel. Wi= th vm.max_wired=3D786432 I have seen the amount of real memory tied up in page= fixing (a.k.a. "wiring" in Berkeley dialect) exceed 6700 MB on an 8 GB machine. My view is that vm.max_wired should either be honored or removed from the source code tree. It is worth noting that ZFS ARC does not appear to be to blame. It ra= rely exceeds the quasi-limit of vfs.zfs.arc_max by more than ~200 MB. The following sysctl variables, when set to very increased values from their default values, seem to help keep a system able to do work or to be recover= able to such condition without the necessity of a reboot: vm.v_free_min, vm.pageout_wakeup_thresh, vm.pageout_oom_seq. Reducing the value of vfs.zfs.arc_max may also help, depending upon your system's configuration. Also, be aware that maintaining a large ccache directory tree to use with "= make buildworld", "make buildkernel", or "portmaster -a" will save you a great d= eal of time, but will also hasten the day when a reboot will be necessary. My advice for those cases is to keep CCACHE_DIR and, for buildworld and buildkernel, /usr/ports or other DESTDIR, in a file system that can be easi= ly unmounted and, perhaps, remounted in order to free up its associated buffer cache memory (most of which should have been pagefreed immediately upon completion of an I/O operation long since anyway). There is not enough pagefreeing being done by the kernel anymore that used to be done at appropriate times or so it appears. Also, if you use ZFS, it will help to reduce the l= imit on ZFS ARC size by setting vfs.zfs.arc_max. Note, however, that that is me= rely a crutch to give you more operational time before you have to intervene manually. FWIW, my speculation is that this mess of bugs of the kind that should have vanished from FreeBSD by release 1.x was introduced into 13-CURRENT and lat= er backported into 11.2 and 12.x. (I am aware that it affects 12.1, but I do = not know whether 12.0 was affected. I currently am running 11.4-STABLE at r364= 474. I do not think these bugs have much, if anything, to do with the graphics stack, but rather appear to be VM subsystem bugs. My system still suffers from th= em, even though there is no safe-to-use graphics support for a Radeon HD 5770 c= ard, and therefore my system is not running X11. :-( --=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-250226-7141-zSk9Dv1pFi>