From owner-cvs-src@FreeBSD.ORG Wed Jul 21 01:14:43 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E936A16A4CE; Wed, 21 Jul 2004 01:14:43 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A64BD43D2F; Wed, 21 Jul 2004 01:14:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-121-219-69.dsl.snfc21.pacbell.net [68.121.219.69])i6L1EfUK091552; Tue, 20 Jul 2004 21:14:42 -0400 Message-ID: <40FDC381.1030802@elischer.org> Date: Tue, 20 Jul 2004 18:14:41 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Peter Wemm References: <200407210029.i6L0TLv0024324@repoman.freebsd.org> In-Reply-To: <200407210029.i6L0TLv0024324@repoman.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 01:14:44 -0000 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? and if it does, does it do those in the cache? 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 > >