On Thu, 29 Oct 1998 08:29:56 +0100 (CET) 
 Sean Doran <smd@ebone.net> wrote:

 > | This is UVM's way of telling you, "I'm out of memory, and out of swap, and Mach
 > | VM would have just wedged at this point."

Uh, not really.

I wrote that panic message :-)  I can tell you exactly what it means :-)

That function, pmap_alloc_physpage(), is allocating a page of memory for
the pmap's use.  That use could be as an L1, L2, or L3 page table or as a
page to chop up into pv_entry_t's.

The situation here could be that the VM system needs to map something
so that it can do I/O to swap, so it calls the pmap, and the pmap needs
to allocate a data structure, but the free list is empty so it tries to
allocate a page, but there aren't any left...

So... the pmap tries to recover in this case.  Since we're desperate, we
use desperate measures.  So, we traverse the list of all pmaps looking
for one which is not active (there will be at most one active pmap per
CPU).  When we find one, we pass it to pmap_collect().

pmap_collect() is normally called when a process is being swapped out,
and the pmap takes this opportunity to free all of the now-unused
mapping resources.  All mappings are flushed, automatically freeing
all of the page tables and pv_entry_t's corresponding to that pmap.  These
pages are now available to the system.

So, I guess what's happening is that you're STILL losing.  I.e. you REALLY
are running out of pages, period.  Since pmap routines have no way to fail,
they simply panic when they can't perform their function.

 > Moreover, the panic happens predictably when I try to do a make cleandir
 > in lib/libc.  Intuition suggests that maybe it's attributes-cache related,
 > but I haven't gone poking around at all to look for something that
 > needs lots of physical memory and not virtual memory.  The lack of a
 > stack trace doesn't help. :(

Make is a memory pig.  Sigh.  Actually, I really would like to know where
all the memory is going, and which pmaps have been pmap_collect'd as part
of the "oh foo, let's free up some memory fast!" process.

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 650 940 5942