Public Discussions > General Discussion
QSINIT updated - now with HPFS support for the ramdisk
Dave Yeo:
What Boris means is that you should be able to have 3 programs each allocating 2 GBs of memory each. The 4GB (actually closer to 3.5GB as the upper is used by BIOS, PCI etc) is a per process limitation and IIRC the i486 can keep track of something like a TB of virtual memory.
Another limitation is that the swap file itself is limited to 2GBs, might be patchable to 4Gbs.
Doug Bissett:
--- Quote ---What Boris means is that you should be able to have 3 programs each allocating 2 GBs of memory each.
--- End quote ---
Well, that is likely to never happen, unless the OS/4 project makes some huge strides (unlikely, from past performance). You have 4 GB (okay, 3.5 GB) to work with, and that is the limit. However, if each program used 1 GB of "extended" memory, it would be possible to do as suggested.
--- Quote --- IIRC the i486 can keep track of something like a TB of virtual memory
--- End quote ---
I doubt if they can, but even if they can, OS/2 cannot. It is designed to work with an addressing scheme that is limited to 3.5 GB. Whatever is done to add more memory access must either work outside of what the kernel knows about (like the RAMDISK) or, the kernel requires major modifications. I know which one is most likely to happen.
--- Quote ---Another limitation is that the swap file itself is limited to 2GBs, might be patchable to 4Gbs.
--- End quote ---
I suspect that there isn't much point. You would need to page out ALL of memory to use it. If memory is available, it would not be paged out. Either that, or there wouldn't be enough real memory for the system to run in. I believe that the term was "thrashing" to death. The swap file is just an extension of real memory, and that still has the 3.5 GB limit.
The "extended" memory would need to be used more like a high speed, direct access, temp file, bypassing the file system. Today, the RAMDISK can be used in that way, but the temp files need to be accessed through the file system (including caching), which adds some overhead.
From what I have seen, there are not many modern programs that make much use of TEMP files anyway, and those files tend to be small, so there is limited benefit from that approach, today.
We have a new toy, but we need to figure out how to use it effectively.
Dave Yeo:
You're misunderstanding the difference between address space and virtual address space. Just with segments there is actually 256 segments of 4GB each available and OS/2 understands this.
The hardware itself allows a large virtual address space and has the means to keep track of it and the OS supports this to an extent. Of course OS/2 is old and they didn't put much work into, what at the time was considered insane memory usage but the capability is there. 32 bit NT as an example can easily use swap files that are larger then 4 GBs, eg see http://en.wikipedia.org/wiki/Paging#Windows_NT where they casually mention creating 6GB and 16 GB swap files.
Another example is OS/2 1.x where the directly addressable memory on a 286 was 16 MB yet the total virtual memory limit was 1GB which is where our low memory limit comes from (half for apps and half for the OS).
We should be able to, amongst multiple programs, allocate about half a TB of memory with the other half given to hardware and OS overhead. (Probably less due to limited amount of page table entries, but that can be worked around by using 1 (4?) MB pages instead of 4KB pages)
Doug Bissett:
--- Quote ---You're misunderstanding the difference between address space and virtual address space. Just with segments there is actually 256 segments of 4GB each available and OS/2 understands this.
--- End quote ---
That is what the hardware is capable of doing. OS/2 doesn't use it that way, and I doubt if it "knows how", or somebody would have figured it out, by now.
--- Quote ---Of course OS/2 is old and they didn't put much work into, what at the time was considered insane memory usage but the capability is there.
--- End quote ---
In fact it is still insane memory usage. Unfortunately, there are more insane programmers around. ;D
--- Quote ---Probably less due to limited amount of page table entries, but that can be worked around by using 1 (4?) MB pages instead of 4KB pages
--- End quote ---
If somebody can figure out the page handling system, the problem could likely be solved. The kernel would still be limited to 3.5 GB addressing, but that 3.5 GB could be a different 3.5 GB space than the next program is using (not quite that simple, I am sure, but...). In fact, I got the impression that that is exactly what PAE addressing does. The problem is with managing it, and telling the kernel that programs can actually have overlapping addresses (in different address spaces). I think it would be much easier to simply work outside of the kernel, for private data storage, but the interface needs to be defined, and programmed. If that is done, the shared memory space can be expanded into the area vacated by the private memory. Not a "perfect" solution, but it should be possible, without trying to mess with the kernel, for somebody who understands the concept. Then, programmers would need to change their memory calls to access it that way.
Navigation
[0] Message Index
[*] Previous page
Go to full version