> [ moved to port-vax -- BCC'd to source-changes so they know it's moved... ]
> 
> On Fri, Feb 22, 2002 at 03:16:28PM +0100, Anders Magnusson wrote:
> 
>  > Eeeek! Now the kernel cannot boot on standard VS2k and other small-memory
>  > machines anymore! The old 24M data size was carefully calculated...
>  > Please revert this, the solution is to remove the sbrk() interface
>  > to get rid of this problem. (I'm testing a solution for this).
> 
> Oh, you mean bumping MAXDSIZ.  DFLDSIZ is only there for initializing
> the default data size.
> 
Oh, yes, this is due to the HW constraints. (Gee, this must be the 100'th
time I describe this the latest 8 years. I should do it a FAQ :-)
HW basics:
A page is 512 byte.
A page table entry mapping one page is 4 byte.
The vax only have one-level page tables.

> 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.
The user page table must be in kernel virtual contiguous memory which
is mapped directly by the system page table.

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.

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.

Why cannot this be solved as it was in the 3BSD VM system then, by 
letting a process allocate more pte space when it grows? Because of
the way sbrk/mmap interacts; all mmap'ed memory is above MAXDSIZ and
therefore all space between the break and MAXDSIZ must have at least
system pte's associated with it.

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.

Did it get any clearer? :-)

-- Ragge