Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 Jan 2017 09:14:27 -0800
From:      Matthew Macy <mmacy@nextbsd.org>
To:        "Jonathan Anderson" <jonathan@FreeBSD.org>
Cc:        "" <markj@freebsd.org>, "" <alc@freebsd.org>,  "freebsd-current Current" <freebsd-current@freebsd.org>
Subject:   Re: PQ_LAUNDRY: unexpected behaviour
Message-ID:  <15974c6426d.12945df5e62589.5931208946643250381@nextbsd.org>
In-Reply-To: <74A6C6D0-90A4-4DB2-8D89-5D2B1E495F88@FreeBSD.org>
References:  <CAMGEAwBknRjecXFyyFGWFQtstX1OiOUvQoVsb9RXj7rmMQ6dDA@mail.gmail.com> <1596d0f6d6d.1266583c3319360.3590554896761456790@nextbsd.org> <74A6C6D0-90A4-4DB2-8D89-5D2B1E495F88@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

 > > 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.

-M








Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15974c6426d.12945df5e62589.5931208946643250381>