X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: HELP with DPMI under DOS - Part II Date: Sat, 25 Oct 2003 23:30:04 CDT Organization: Rice University, Houston, TX Lines: 78 Message-ID: <3f9aec88.sandmann@clio.rice.edu> References: <3f99c179$0$164$cc7c7865 AT news DOT luth DOT se> NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1067143343 21147 128.42.105.3 (26 Oct 2003 04:42:23 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: Sun, 26 Oct 2003 04:42:23 +0000 (UTC) X-NewsEditor: ED-1.5.9 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > : Due to the size of a 1GB-4GB address space, you will get sub-optimal > : performance using 4KB pages since the address lookups can't all be cached. > > Yes. So what? Do we want standard compliance that works everywhere? Or > a hack that works only if special circumstances apply? The DPMI 0.9 specifications will still be supported. The DPMI 1.0 specification doesn't talk about multiple page sizes or 4MB pages - which isn't surprising since it was written before the hardware which supports this existed. So some of the DPMI 1.0 functions that do page protection (null pages) or page mapping might not work on a 4MB page. The DPMI provider could then break up that page if needed into 4KB pages to support these functions, or it could fail them. The 4MB page size code could be transparent to the application. But since CWSDPMI doesn't fully support the DPMI 1.0 specification, and the use of the DPMI 1.0 calls is *VERY* rare (only the null page protection usually) - I wonder if it is worth the effort. (First pass I decided not). All of the users who have contacted me about > 500MB of memory under DOS have mentioned the following requirements: 1) Ultimate performance - better than other OSes, and 2) Maximum memory - preferably more then 2GB (not available elsewhere). So far no one using the work in progress r6 has complained about about 10 things which are broken with DPMI 1.0 features on 4MB pages. But all have pointed out relatively large performance improvements. So I'm convinced that I can provide DPMI 0.9 compliance, and mostly backward compatible DPMI 1.0 features which CWSDPMI provided before, and improved large memory support - all in the same image. The 4MB page stuff is only active when a request for more than 4MB in a single request is made, the page table for that 4MB space doesn't exist yet. I don't page 4MB pages either. It's been suggested that I limit 4KB pages to the first 256MB of memory and use 4MB pages for the rest, and only enable it with more than 256MB physical. But I haven't done anything on it in 2 years (people with the test image are happy so far). > Yes. But as you said yourself that won't be VCPI compatible. That's because VCPI doesn't support 4MB pages: 1) when you ask for memory it gives it to you 4KB at a time 2) you share page tables with VCPI, and it might fry it's brain If VCPI supported these features, then I don't see a problem. > I don't myself see why that won't be VCPI compatible if the first 4MiB > is mapped with ordinary 4KiB pages. You should be permitted to do > sever abominations above 4MiB. Still the problem of allocating memory in 4MB contiguous, aligned chunks. And I would never be sure that a VCPI server wouldn't freak if it saw a 4MB page in the page directory. > Yes. But you also decided to be not VCPI compatible. Not completely true. When I started there was no VCPI server available which would serve more than 500MB of physical memory. The r6 work in progress still works with VCPI, it just doesn't attempt to use 4MB pages. Since memory was always to much less than 500MB by the VCPI server, no one interested in large memory would run VCPI. There are bad bugs in EMM386 which occur when you try to run it on systems with huge amounts of memory. If we did a full testing of VCPI servers, and found that none had problems with 4MB pages then I would consider additional support. So I've currently chosen not to even try under VCPI, due to potential problems, implementation issues and complete lack of demand for this environment. > : PMODE avoids the issue completely by not turning on paging at all > : unless it must to deal with VCPI. > > And what will happen if PMODE finds itself in a VCPI environment? Under VCPI it allocates the number of page tables needed to completely map the physical memory (in DOS memory space). So it would also fail with more than 500MB or so of physical memory under VCPI.