From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10010230218.AA15945@clio.rice.edu>
Subject: Re: Announce: CWSDPMI r5 public beta
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 22 Oct 2000 21:18:58 -0500 (CDT)
Cc: djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1001022125955.3937A-100000@is> from "Eli Zaretskii" at Oct 22, 2000 01:00:20 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Message-ID: <39f2f37e DOT sandmann AT clio DOT rice DOT edu>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001022125955 DOT 3937A-100000 AT is> <39f1c1c6 DOT sandmann AT clio DOT rice DOT edu>

> Sorry, I'm not sure I'm following the calculations.  How much memory
> does CWSDPMI need for the page tables per 1MB of extended memory it
> manages?

CWSDPMI needs 1Kb of DOS memory for each 1Mb of address space.  When it
does the "auto" calculation (in r4 and non-fixed r5) it would take the
size of the physical memory and make that the assumed address space
(with a minimum of 20Mb/20Kb - assuming small memory machines may page
much more).  So, for r5 I'm adding an upper limit of 128Mb (128K) to
that automatic page directory calculation (which is less than the
256Mb/256K maximum under r4).

> However, what I had in mind, additionally, was a CWSPARAM parameter
> that would preclude CWSDPMI from using more than X Kbytes of DOS
> memory for the page tables.  Unless I'm missing something, this means
> in practice that, when CWSDPMI gets to that number, it will stop using
> more physical memory, and start paging to disk instead.  If I'm right,
> this seems to be a good compromise for someone who wants to use as
> much physical RAM as possible without risking failures to run deeply
> nested programs.  E.g., some complex packages need 6 or 7 nested
> programs to build them.

What would actually happen is if you used the DOS memory and couldn't
get any more, you start paging the page directories themselves.  This is a
huge performance hit (especially if you don't have a disk cache) since
each page directory represents 4Mb of memory.  But it's only a problem
if you are using lots of memory ....

I suspect the 128Mb "max" will be about right - since this will make the
max CWSDPMI footprint around 200K - and even with a bunch of network
drivers (say only 400K free to start with) you would still have enough to
nest about 10 deep or something.  Humm, if you had 2Gb of memory that
might be 260K with the bitmaps - but still reasonable.

I still think some parameter to limit address space size is a good idea,
as is one to control DOS memory - but not for r5 if I can avoid it.  I've
made new r5's maximum memory footprint actually less than under r4 - so I
doubt it's a pressing concern since this was never a complaint under r4 ...