| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.