> 
>    The memory mapping is not so good, mainly because it does not seem easy
>    to use the very large virtual address space. If information is placed
>    at random the page tables become huge (2^21 words!). However, the user
>    page tables can themselves be paged, and this may provide an out.
>    [...]
> 
> I remember my Computer Organization and Assembly Language professor
> mentioning this, but I either figured I had mis-heard him or I thought
> that he was on drugs.  I know that one of the issues we have with
> NetBSD/vax is that we've got pretty a fairly limited maximum process size
> because of the problems with large page tables.  Within the design of
> NetBSD, would it be possible to make use of this feature of being able to
> page out our page tables? :-)
> 
NetBSD/vax already uses this "feature", but it's not the user page tables
that is the problem, it's the "system page table" (SPT). Simple explanation:

A VAX page table entry (PTE) is 4 bytes and maps one 512 byte page.
The total addressable user virtual address space is 2GB; to map that
it would need 16MB of (pageable) page tables. This is per process.
If the system can handle 100 processes the virtual address space that
would be allocated in the kernel would be 1600MB. To map this virtual 
space 12.8MB of physical pre-allocated memory would be needed. That's
much in a 8MB machine... :-)

A way to avoid this, which I plan to implement, is to have only a small
number of User PTE "slots", and when there is a process switch the kernel
first checks if the new process have a slot already. If it has, just a 
"normal" switch is done, if it hasn't, use LRU to throw out the oldest
process. This wouldn't give any noticeable performance penalty except 
if the number of running processes (running, not existing) exceeds
the number of slots.

The number of slots would be a compile-time constant.

-- Ragge