At 10:34 PM 2/22/2002 +0100, Anders Magnusson wrote:
> > [ 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.

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. :)

>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.

>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.

>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.

>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.

True.  But they need not be active.  To map 1GB of address space (the
most allowed in either P0 or P1 (or even S0) space 128 SPTEs are
required.  The following in VAX physical pages.  A P0/P1/S0 PTP (page
table page) holds 128 PTEs covering a contiguous 64KB of address space.
That 64KB if it contains PTEs (16K PTE x 512) will map 8MB of address
space.  Thus 128 SPTEs (the amount of PTEs contained in one VAX page)
can refer to 2M PTEs to eventually map 1GB of address space.  This
requires 16384 user PTP (using 8MB of address space) and one system
PTP.

The important thing to know is not all page table pages need be
allocated.  If I ask for address 0x100000 and it isn't mapped by
one of my user PTPs, an ACCVIO exception is raised and that can be
dealt with.  But if the MMU while accessing the PTP that would map
that page, found that the user PTP was not mapped in the system page
table, the access violation would be for the PTE in the user PTP.
Then the fault handling could would know to restore that page into
the system page table and retry the fault.

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.
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.

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.

>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.


-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message