TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: Dean Roddey
from: David Noon
date: 1994-10-15 17:27:16
subject: 512mb Is Ample Right Now

On Tuesday, 1994-10-11  Dean Roddey wrote to David Noon about "512mb
Is Ample Right Now" as follows:

DR> DN> complete file mapping simply because the buffer lookasides on
DR> DN> a full file mapping scheme would cause excessive page faults.
DR> DN> Even with sparse page-frame allocation, as soon as a page-frame
DR> DN> is referenced it must be committed. If this can cause problems
DR> DN> on a 10GB mainframe with 500TB of 
DR> 
DR> But, OS/2 allows you to decommit page, which would give back the
DR> physical memory and 'reset' the fault in of the pages? I've used
DR> sparse allocation but I haven't had a need to decommit so I'm not
DR> for sure if it's doable. So the exception handler would be able to
DR> use an LRU algorithm to decommit old pages and map new ones in. So
DR> the a single 64Meg (for instance) block could continually be used
DR> to manage a file of any size without the physical memory
DR> commitment growing cancerously (is that a word?.)

Hi Dean,

Well, the way a well-written MVS application deals with this is that
it remaps an already committed page to another part of the disk file.
It saves removing one entry and adding another in the Page Descriptor
Tables (equivalent of LDT's under OS/2) and is generally considered
more efficient than removing the page from commitment and committing a
new page. This is particularly true in a SMP environment, where the
PDT's are cached and any context switch that also switches from one
processor to another causes the cache of PDT's to be flushed and
rebuilt on the other processor. [The page fault can, itself,
precipitate the context switch, since control of the machine returns to
the dispatcher.]

I would expect similar performance issues to appear in a SMP
environment under OS/2 (and Windows NT). This experience of SMP issues
is quite well established in the mainframe world, since the big-iron
has had SMP systems since the 1960's and caching SMP's since the early
1980's. I just hope that we use the mainframe experience of 8 or 10
years ago to avoid the same pitfalls when accessing files using
memory-mapping.

Regards

Dave

 * KWQ/2 1.2g * I have so much mail, I've sinking in .QWKsand...

--- Maximus/2 2.01wb

* Origin: OS/2 Shareware BBS, Fairfax, VA: 703-385-4325 (1:109/347)
SEEN-BY: 12/2442 54/54 620/243 624/50 632/348 640/820 690/660 711/409 410 413
SEEN-BY: 711/430 807 808 809 934 942 949 712/353 623 713/888 800/1
@PATH: 109/347 2 7 3615/50 229/2 12/2442 711/409 54/54 711/808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.