> 
> > The user page table must be in kernel virtual contiguous memory
> 
> Not for the KA620; the KA620 puts P0 and P1 ("user") page tables in
> physical memory, not system virtual memory.  (Of course, how much
> anyone not doing highly-custom embedded systems cares about the KA620
> is another story.)
> 
Gee, I had luckily forgotten that arch :-)

> > This means that the user page table must have space allocated in the
> > system page table before memory management is turned on.
> 
> Not quite.  All you need to do is allocate physically contiguous memory
> later and you can move the system page tables around after boot.  (That
> may be difficult to do under the assumptions NetBSD's MI code currently
> makes; that's a different issue.)
> 
I don't really think it would be realistic to try to implement such 
feature :-)

> Also, there's no reason in principle that the system page table can't
> have holes - invalid PTEs (or perhaps they have to be valid but
> no-access) each representing 64K of nonexistent/invalid userland space.
> 
You can, and that's the way the NetBSD/vax pmap works :-)

[ many ideas about moving around the process address space ]
> 
> Of course, that juggle may come at a higher price than removing sbrk.
> That's a judgement call for you people to make.  I just point out
> possibilities. :-)
> 
Thanks, I have tried to move around things a bunch already, just for 
test purposes (like letting all mmap() go in P1 space). The problem
is that it's just workarounds for the bad mmap/sbrk interaction.

-- Ragge