cvs commit: src/sys/vm vm_map.c
alc at cs.rice.edu
Tue Jul 20 20:22:16 PDT 2004
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
More information about the cvs-all