netbsd@precedence.co.uk said:
> It's been under discussion on and off since the 1.1 days and the start
> of the arm32 port. I could be way wrong on this, but my understanding
> is that the L1 (i.e. primary) page tables each hold the mappings for
> the rest of the memory space for a process. They are 16k each. On
> arm32, a number are statically allocated at boot time with either a
> kernel option (PMAP_STATIC_L1S) or with a maxproc option at boot time
> (the former taking precedence). I believe that there is some attempt
> at dynamic allocation beyond this, but as the physical memory needs to
> be contiguous (16k - 4 4k pages), allocation is usually unsuccessful
> and therefore the machine runs out of L1 tables. This means the
> machine deadlocks waiting for a process to terminate before a new one
> can start. In addition, settings PMAP_STATIC_L1S too high cause the
> machine to fail to boot up (I believe 256 is sufficient to stop the
> CATS, though I've not tried recently). The upshot of this is that you
> can only run about 200 processes at once on arm32. Thus it's pretty
> useless for running something like Apache where there is a fork for
> each request. 

It's not just that you need a contiguous block of 4 x 4K pages, but that 
the block must be 16K aligned.  Asking the VM system for this is (was?) 
difficult if not impossible.

R.