Date:	Sun, 22 Oct 2000 13:00:20 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	djgpp AT delorie DOT com
Subject:	Re: Announce: CWSDPMI r5 public beta
In-Reply-To:	<39f1c1c6.sandmann@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1001022125955.3937A-100000@is>
MIME-Version:	1.0
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

On Sat, 21 Oct 2000, Charles Sandmann wrote:

> > How about a default that would leave enough DOS memory for some
> > reasonable number of nested DJGPP programs (2? 3?), in addition to a
> > CWSPARAM parameter that controls how much DOS memory can be used?
> 
> The current default "leave it alone" dos memory is around 64Kb, which should
> be enough for 4 more nestings.  But the current page table request was
> bypassing that.  I was then thinking about how many people need to use
> more than 128Mb, versus how many people might want that memory for everything
> from nesting programs to DMA buffers.  Somewhat arbitrarily I decided that
> an initial allocation of 128Mb worth of pagetables (if you have more than
> 128Mb of memory) should be enough.  On a typical machine, this is still
> going to leave probably 300Kb+ of DOS memory free.

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?

> And CWSDPMI will still
> try to allocate that memory on demand if you touch more than 128Mb of 
> memory.  (The later allocation should be avoided since it fragments DOS
> memory and causes some alignment memory waste).  This is the "auto" choice,
> and you still have the ability to override this with CWSPARAM if you don't
> like it.

I think this "auto" operation is okay, even with the caveats of the
late allocations.

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.

> I could try to do something more complicated, but at this point I'm afraid
> of breaking something this soon before a release.

I agree that, at this point, if even the additional parameter I
suggest above is too risky to implement, that the current situation is
not too bad.

- Raw text -