On 5 Jan 2017, at 0:17, Matthew Macy wrote:

---- On Mon, 02 Jan 2017 06:01:50 -0800 Jonathan Anderson <jonat...@freebsd.org> wrote ----
Hi all,

I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of not-quite-CURRENT, it's also very possible that I don't understand how the laundry queue is supposed to work. Nonetheless, I thought I'd check whether there is a tunable I should change, an issue with the laundry queue itself,

After running X overnight (i915 can now run overnight on drm-next-4.7!), I end up with a little over half of my system memory in the laundry queue and a bunch of swap utilization. Even after closing X and shutting down lots of
services, I see the following in top:

Please try the drm-next branch now. Up until very recently, the shrinkers responsible for culling ttm/gem allocations were never run. I've now implemented the shrinker, but it's driven from vm_lowmem, so you'll probably still see what looks like a leak until you hit low memory conditions. The shrinker should probably be run from uma_timeout, but there isn't an eventhandler for that and I haven't looked any further.



I am now testing the `drm-next` branch, but I'm finding it crashes much more frequently (a la https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than `drm-next-4.7`. While the 4.7 branch would sometimes only last a few minutes, it would sometimes run for a day or more. On `drm-next`, however, I think I'm yet to have 20 minutes of uptime. So, I haven't run into the memory shrinker yet because I haven't had enough uptime to use lots of memory. :) I will continue testing... any specific things I ought to be doing?

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to