Date: Tue, 27 Jan 2004 10:24:44 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no> Cc: current@freebsd.org Subject: Re: 'kern.maxpipekva exceeded' messages... Message-ID: <20040127101910.P4636@odysseus.silby.com> In-Reply-To: <xzpznc9tzgz.fsf@dwp.des.no> References: <20040119233546.S39477@odysseus.silby.com> <xzpznc9tzgz.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Jan 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Mike Silbersack <silby@silby.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040127101910.P4636>