Date: Tue, 20 Jul 2004 18:14:41 -0700 From: Julian Elischer <julian@elischer.org> To: Peter Wemm <peter@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c Message-ID: <40FDC381.1030802@elischer.org> In-Reply-To: <200407210029.i6L0TLv0024324@repoman.freebsd.org> References: <200407210029.i6L0TLv0024324@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40FDC381.1030802>