> >
> > > Sigh, this is a real bummer ... what this really does is point out the
> > > design flaws in the VAX pmap.  If memory is really that tight, perhaps
> > > the VAX should not be using a linear PTE mapping.
> > >
> >Cannot be changed; it's the hardware design:
> >The system page table must be in _physical_contiguous_ memory.
> 
> True.  But then, not all of the system page table entries need point to
> an active page.  In fact, since the VAX pmap currently maps all of physical
> memory, current VAX system can't use more than 1GB of RAM.  Though this
> isn't a problem for most of the machine running NetBSD/vax, it is
> something to think about if a VAX9000 is ever supported. :)
> 
Actually, when I wrote the pmap, I wasn't aware of the extended addressing
machines :-) (and on those machines memory limitations won't be a problem
either...)

> >The user page table must be in kernel virtual contiguous memory which
> >is mapped directly by the system page table.
> 
> Yes and no.  Each of the process's P0 and P1 page table must be in
> kernel virtually contiguous address space.  However, again, not all page
> table pages need be active/valid.
> 
Of course not. If that had been the case there had been a much bigger
need for memory than it is today.

> >This means that the user page table must have space allocated in the
> >system page table before memory management is turned on. This is the
> >big problem (system page table grows too large) and it must be allocated
> >before the system starts.
> 
> Completely false.  The current pmap requires that, not the VAX MMU.
> 
Eh, no. You must have space allocated for the process that you want to
be able to run, otherwise you may not be able to start more processes.

> >If you can find a way to get around this, you'll be a hero. Noone else
> >has been able to do it for 25 years :-)  IIRC the oldest place where
> >I saw this HW limitation problem mentioned as a problem was in the
> >papers describing the rewriting of the VM system in 3BSD.
> 
> VMS has gotten around from day 1.
> 
No, VMS has not gotten around it, VMS have a quite different process
layout that do not not allocate process space up to 64MB or so in all
processes.  So worked 3BSD also, but that was pre-mmap. The problem
is the same.

> 
> So the real problem is that the system address allocated to user PTPs
> is always backed by real memory.  This is very wasteful and inefficient.
>
From where have you got that idea? It isn't and have never been so, 
if it had then almost no processes had been able to run at all.
Only those page table pages that actually maps anything do exist.

> The proper was to do this is allocate a reasonably large amount of
> system address space (note that 16MB (two pages worth of SPTEs) is
> enough to allow for a process to have a full address space) and only
> map a process'es PTPs when active or when there is active I/O on those
> pages mapped by the PTP.
> 
You mean having a user pte map that is smaller than the total sum of all
process space, and then allocate the needed amount from it? That won't
work because all processes always maps the full possible space (due to 
the dynamic linking libraries).  The pmap was implemented in that way once,
but it didn't work when binaries started to mmap() thing.

Another way of solving the problem is to have a smaller "pool" of 
SPT process spaces, and use LRU to allocate space for processes when
they are run. I implemented that a few years ago, but it failed 
totally when processes started to compete about process space.
(cat something_big | awk '{print}' | awk '{print}' ...)
It doesn't solve the big problem either; all processes that runs
_must_always_ have the whole of its P0 space mappings available in
kernel virtual memory due to mmap(). That's the fact.

> The above is why the VAX pmap module is on my TODO list after I finish
> VAX ELF support.  Basically to allow any VAX process to be able to have
> a reasonable amount of address space.
> 
Please, don't try to do something that is already tested and failed in
some way. I have tried (probably) all possible ways to deal with this
the latest 8 years.

> >The solution to this would be to remove the sbrk interface from kernel
> >and then let malloc use mmap instead. I have the phk malloc rewritten
> >to use mmap (actually it got slightly faster) and routines that emulate
> >sbrk via mmap, I just wanted to test it some more before I write a
> >proposal about it.
> 
> It's a solution but probably not the right solution.
> 
Why not? 

It would minimize the amount of needed space on the SPT for all processes
to a minimum which would make it quite possible to allocate enough space
from a small map, just as in 3BSD. 

-- Ragge