From owner-cvs-all@FreeBSD.ORG Thu Jul 10 11:24:39 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EA3C37B401; Thu, 10 Jul 2003 11:24:39 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81BE943F93; Thu, 10 Jul 2003 11:24:38 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h6AIOaLv009921; Thu, 10 Jul 2003 11:24:36 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h6AIOaK5009920; Thu, 10 Jul 2003 11:24:36 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 10 Jul 2003 11:24:36 -0700 From: David Schultz To: "Alan L. Cox" Message-ID: <20030710182436.GA6484@HAL9000.homeunix.com> Mail-Followup-To: "Alan L. Cox" , Mike Silbersack , Don Lewis , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org References: <200307080457.h684vRM7009343@gw.catspoiler.org> <20030708000257.D6158@odysseus.silby.com> <20030708004340.T6733@odysseus.silby.com> <3F0B199E.A3C980D2@imimic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0B199E.A3C980D2@imimic.com> cc: cvs-src@FreeBSD.ORG cc: Mike Silbersack cc: src-committers@FreeBSD.ORG cc: Don Lewis cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_param.c sys_pipe.c src/sys/sys pipe.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2003 18:24:39 -0000 On Tue, Jul 08, 2003, Alan L. Cox wrote: > Mike Silbersack wrote: > > > > On Tue, 8 Jul 2003, Mike Silbersack wrote: > > > > > If I spend more time working on pipes, there are a bunch of other changes > > > I'll be working on first. > > > > > > Mike "Silby" Silbersack > > > > Let me explain this statement a little better, as it helps explain why I > > didn't do per-user limits in the initial commit. > > > > As pipes are implemented now (which basically still follows John's > > original design), for each side of a pipe we allocate: > > > > 1 VM object which is linked to > > 16KB of address space from the kernel map; > > this is pageable, and acquires backing as it is filled. > > > > For large writes which align on page boundaries, the pages are wired into > > kernel memory, and shown directly to the reading end of the pipe. > > Naturally, this memory isn't pageable, and is even more important to > > limit. (However, as stated in my commit message, this _can_ be limited > > without any nasty sideeffects.) > > When "pages are wired into kernel memory" there are two distinct actions > being performed: vm_page_wire() and pmap_qenter(). However, as far as I > know, there is no reason why the pmap_qenter() has to be performed by > the sender. I suspect the mapping could be delayed until just before > the copy and released immediately thereafter, thereby eliminating the > need for each pipe to have its own KVA for this purpose. In fact, I > believe the sf_buf allocator could be used to provide the temporary KVA. That would alleviate the KVA pressure, since the mapping would be very temporary and you could even get away with just a single page. However, it would still tie up the associated physical memory until the pipe is read, which may not be soon at all. Is there a reason for the memory to be wired, other than that the data is easier to track down while the sending process' PTEs are still there? I would expect that you could instead just look up the appropriate vm_object and lazily fault in the appropriate pages on the receiver's side, modulo a few details such as segfault handling. But perhaps I'm missing something...