> > But the fundamental problem is that there is no way to ask the paging 
> > system to free up a 16K-aligned block of memory -- all you can ask for is 
> > 4 pages, so we end up in the situation where the paging system thinks 
> > there are enough free resources, but the vm system doesn't.
> 
> To avoid a complete rewrite of the paging system, could you timeout
> and retry, asking the paging system for more free pages each time?

Not from within the pmap code, the pmap asks uvm for a 16k, 16k-aligned 
chunk of memory, it's the uvm system that asks the paging system to 
reclaim the memory.  The paging system wakes up; decides that enough pages 
are already available to fulfil the request and goes back to sleep again.

> Make fork should fail EAGAIN after a timeout as well?

It's too late to fail with EAGAIN at that point; state has been created.  
Besides, the pmap has no way of indicating to UVM that it can't get a L1 
table (which is why it has to sleep in this case).

> But swapping them (or stealing one from an idle process?)
> may be better.
> 
> Thinking about the free list, I'm not sure keeping entries in case
> you can't allocate 1 would be an advantage.
> You would have the preserve the last entry for root, and probably
> for an interactive shell that isn't in a fork bomb...
> 
> The freelist is (presumably) there to avoid the expensive allocate
> when running shell scripts (etc).

It should probably be done using the pool system rather than having our 
own private stash, but yes that's the general idea.  Plus, I think the 
argument goes, if you've used that many L1s before, then you are likely to 
again, so better make sure we hang on to some suitably aligned memory.

A final, brute-force approach to the problem might also be,

Find 4 (consecutive, 16k-aligned) physical pages that are not wired but 
are used for user-space accesses, and 4 physical pages that are not 
allocated; implement a uvm interface to forcibly migrate the physical 
pages to the new pages and then to release the freed up pages as a chunk; 
since the virtual addresses never change, and since they aren't wired down 
in any way, the system should be oblivious to the fact that the memory has 
been moved.

R.