Subject: Re: CVS commit: syssrc/sys/arch/vax/include
To: Anders Magnusson <ragge@ludd.luth.se>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: source-changes
Date: 02/22/2002 11:37:22
[ 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.

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.

You could use direct mapping of PT pages (much like how the VAX port
does with pool pages), and rather than having a pm_refcnt[] array, use
an array of pointers to the pages (or PFN's or whatever, to make the array
more compact), and use the "wire_count" in the vm_page structure as the PT
refcnt (like the Alpha and i386 port do).

This would allow you to do away with the ptemap, the KVA space associated
with the ptemap, and thus the kernel page tables (wired pages) required
to map the KVA space consumed by the ptemap.

...and then the limits could be as large as they want, since all resources
to map the areas controlled by the limits are totally dynamically allocated.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>