Date: Sun, 22 Oct 2000 13:00:20 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: djgpp AT delorie DOT com Subject: Re: Announce: CWSDPMI r5 public beta In-Reply-To: <39f1c1c6.sandmann@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.