> > 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. > > > > -M > > Hi, > > 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? > I just did the merge and it's using a relatively untested new KPI so regressions aren't too surprising I'm afraid. #96 is more or less content free in terms of providing useful information. Getting a core + backtrace would be a lot more helpful. See the repo's wiki for details on improving your odds of getting a core. -MReceived on Fri Jan 06 2017 - 16:14:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC