Hi folks...

I'm still banging away on the pmap :-)

I just checked in some changes that add a fair amount of robustness to
the system.  The changes were:

	(1) Implement pmap_collect().  This allows the pmap to free
	    up memory when a process is being swapped out.  My
	    implementation is simple: just remove all of the page
	    tables for the entire user address space.  The VM system
	    will rebuild them when the process is swapped back in.

	(2) In pmap_alloc_physpage(), which is used to allocate page
	    tables, PV list entries, and other sundry items, if we can't
	    allocate any pages, find an inactive pmap that has some
	    page tables and pmap_collect() it.  This is safe to do since
	    the pmap is free to "forget" mappings at any time; they
	    are really redundant, and will be rebuilt by the VM system.

	    This isn't really optimal; you want to find the _most_
	    inactive pmap and pmap_collect() it, but that has problems
	    on multi-processor systems (most inactive on _which_ processor?),
	    and when this happens, we're desperate anyhow...

These changes allowed my AlphaStation 500 with 256M of RAM (running
UVM+PMAP_NEW, but Mach VM will be helped, too) to withstand 6
concurrent kernel builds are run with "make -j32".  The system
performed over 3200 complete swapouts, and the pmap_alloc_physpage()
change was used several times.

FYI.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939