From owner-freebsd-current@freebsd.org Fri Jan 6 16:42:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 856ECCA2662 for ; Fri, 6 Jan 2017 16:42:05 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66D2C16EA; Fri, 6 Jan 2017 16:42:05 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from [172.31.128.104] (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) by freefall.freebsd.org (Postfix) with ESMTP id 880FA104A; Fri, 6 Jan 2017 16:42:04 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) From: "Jonathan Anderson" To: "Matthew Macy" Cc: markj@freebsd.org, alc@freebsd.org, "freebsd-current Current" Subject: Re: PQ_LAUNDRY: unexpected behaviour Date: Fri, 06 Jan 2017 11:42:04 -0500 Message-ID: <74A6C6D0-90A4-4DB2-8D89-5D2B1E495F88@FreeBSD.org> In-Reply-To: <1596d0f6d6d.1266583c3319360.3590554896761456790@nextbsd.org> References: <1596d0f6d6d.1266583c3319360.3590554896761456790@nextbsd.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 16:42:05 -0000 On 5 Jan 2017, at 0:17, Matthew Macy wrote: > ---- On Mon, 02 Jan 2017 06:01:50 -0800 Jonathan Anderson > 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, >> etc. >> >> 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. > > -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? Jon -- jonathan@FreeBSD.org