[Bug 250226] graphics/drm-fbsd12.0-kmod: massive memory leak

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250226

Scott Bennett <bennett at sdf.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bennett at sdf.org

--- Comment #1 from Scott Bennett <bennett at 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 several
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.  With
vm.max_wired=786432 I have seen the amount of real memory tied up in pagefixing
(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 rarely
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 recoverable
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 deal
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 easily
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 limit
on ZFS ARC size by setting vfs.zfs.arc_max.  Note, however, that that is merely
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 later
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 r364474.
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 them,
even though there is no safe-to-use graphics support for a Radeon HD 5770 card,
and therefore my system is not running X11. :-(

-- 
You are receiving this mail because:
You are the assignee for the bug.