cvs commit: src/sys/vm vm_map.c

[Alan Cox]

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