From owner-cvs-all@FreeBSD.ORG Wed Jul 21 03:22:16 2004 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 60DB016A4CE; Wed, 21 Jul 2004 03:22:16 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49B1643D5F; Wed, 21 Jul 2004 03:22:16 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id D15034AA87; Tue, 20 Jul 2004 22:22:15 -0500 (CDT) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 07924-01-2; Tue, 20 Jul 2004 22:22:15 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id 7EC284AA5D; Tue, 20 Jul 2004 22:22:15 -0500 (CDT) Date: Tue, 20 Jul 2004 22:22:15 -0500 From: Alan Cox To: Julian Elischer Message-ID: <20040721032215.GF18577@cs.rice.edu> References: <200407210029.i6L0TLv0024324@repoman.freebsd.org> <40FDC381.1030802@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40FDC381.1030802@elischer.org> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Peter Wemm Subject: Re: cvs commit: src/sys/vm vm_map.c 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: Wed, 21 Jul 2004 03:22:16 -0000 On Tue, Jul 20, 2004 at 06:14:41PM -0700, Julian Elischer wrote: > Peter Wemm wrote: > > >peter 2004-07-21 00:29:21 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/vm vm_map.c > > Log: > > Move the initialization and teardown of pmaps to the vmspace zone's > > init and fini handlers. Our vm system removes all userland mappings at > > exit prior to calling pmap_release. It just so happens that we might > > as well reuse the pmap for the next process since the userland slate > > has already been wiped clean. > > > > However. There is a functional benefit to this as well. For platforms > > that share userland and kernel context in the same pmap, it means that > > the kernel portion of a pmap remains valid after the vmspace has been > > freed (process exit) and while it is in uma's cache. This is significant > > for i386 SMP systems with kernel context borrowing because it avoids > > a LOT of IPIs from the pmap_lazyfix() cleanup in the usual case. > > > > Just thought of something.. > if the kernel section of a pmap gets changed, > does the system scan all processes to fix them? Yes, we maintain a list of all pmaps on i386. We traverse that list when the kernel's address space grows in size, updating each of the page directory pages. > ... and if it does, does it > do those in the cache? Yes, until you call pmap_release(), the pmap, including cached pmaps, remains in the all pmaps list. > I have to go look at the pmap code again.... > > > > > Tested on: amd64, i386, sparc64, alpha > > Glanced at by: alc > > > > Revision Changes Path > > 1.343 +2 -3 src/sys/vm/vm_map.c > > > > Regards, Alan