From owner-freebsd-current@FreeBSD.ORG Tue Jan 27 08:25:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0100B16A570 for ; Tue, 27 Jan 2004 08:25:28 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0EE9743D75 for ; Tue, 27 Jan 2004 08:25:02 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 47445 invoked from network); 27 Jan 2004 16:24:46 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 27 Jan 2004 16:24:46 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 27 Jan 2004 10:24:44 -0600 (CST) From: Mike Silbersack To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: <20040127101910.P4636@odysseus.silby.com> References: <20040119233546.S39477@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailman-Approved-At: Wed, 28 Jan 2004 06:12:04 -0800 cc: Peter Losher cc: current@freebsd.org Subject: Re: 'kern.maxpipekva exceeded' messages... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 27 Jan 2004 16:25:28 -0000 On Tue, 27 Jan 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Mike Silbersack writes: > > Documenting maxpipekva / reducing pipe memory usage is on my to-do list= =2E > > Unfortunately, I was unable to complete my changes in time for > > 5.2-release; I will try to get them in place soon. > > We seem to have had a regression in this area since 5.1-RELEASE. > Systems that ran fine on 5.1-RELEASE are running out of pipe kva after > an upgrade to 5.2-CURRENT. Should we suspect a leak somewhere? > > DES I do not believe that there is a leak. What actually happened is that between 5.1 and 5.2 I added pipe memory limits, which had not been present before. This is suboptimal for two reasons: 1. Pipes overallocate memory greatly; I could probably reduce the memory usage of an idle pipe by 8x or so. 2. At Alan's request (due to locking issues), I moved the pipes into their own submap of the kernel map, rather than having them allocated out of the main map itself; this required me to put an even larger cap on pipe memory usage, as I did not want to steal too much from the main kernel map. I'll drop Alan a line and see if the locking situation has changed since that time. If you're interested in working on this right now, I can send you what I had planned to do for #1, it would be a very small amount of code, although it would require a bit of testing to ensure that it does not degrade the performance of pipes by a noticeable amount. Mike "Silby" Silbersack