OS/2, eCS & ArcaOS - Technical > Web applications
QT5 simplebrowser
OS4User:
--- Quote from: Dave Yeo on November 20, 2021, 05:45:07 pm ---This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc
--- End quote ---
VAL and virtual memory do not have any relation to physical memory. System will have exactly the same layout and amount (about 4GB) of virtual mem whether it has 4GB or 512MB of RAM installed.
Roderick Klein:
--- Quote from: Dave Yeo on November 20, 2021, 05:45:07 pm ---Seems I did have one system where it did seem to make a difference, but maybe I'm misremembering. In this case it may well have been a coincidence where the reboot fixed things.
I'm not sure if IBM finished the high memory support and a theory is that too high a VAL value on some hardware might intrude into kernel memory space. This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc. I'd assume a video card could eat up more memory at the top end.
--- End quote ---
Few people know that this virtualaddresslimit was already build into Warpserver advanced. It was only later this code was moved into the _W4 kernel. In my book the code is finished. IBM introduced high memory for stuff such as DB2, which could use this high memory.
Now does the code contain bugs, possible. But we need to have proper debug data for that.
Roderick
Dave Yeo:
--- Quote from: OS4User on November 20, 2021, 07:07:57 pm ---
--- Quote from: Dave Yeo on November 20, 2021, 05:45:07 pm ---This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc
--- End quote ---
VAL and virtual memory do not have any relation to physical memory. System will have exactly the same layout and amount (about 4GB) of virtual mem whether it has 4GB or 512MB of RAM installed.
--- End quote ---
4GB's of address space minus PCI memory address space (including video memory) equals 3.2Mb's of address space in my case, and then minus kernel address space, things like the JFS cache. As Dariusz mentioned in a separate thread, he had to lower VAL when he enlarged the JFS cache to get the larger cache to take.
I also discovered that with 1.5GB's of ram and VAL set to 3072, the swap file is limited to 2GB's of virtual memory, likely due to signed variables somewhere. The crash said swap file full even with lots of disk space on a JFS volume. Linking xul back around FF10 really did need the full address space.
Dave Yeo:
--- Quote from: Roderick Klein on November 20, 2021, 07:36:56 pm ---
--- Quote from: Dave Yeo on November 20, 2021, 05:45:07 pm ---Seems I did have one system where it did seem to make a difference, but maybe I'm misremembering. In this case it may well have been a coincidence where the reboot fixed things.
I'm not sure if IBM finished the high memory support and a theory is that too high a VAL value on some hardware might intrude into kernel memory space. This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc. I'd assume a video card could eat up more memory at the top end.
--- End quote ---
Few people know that this virtualaddresslimit was already build into Warpserver advanced. It was only later this code was moved into the _W4 kernel. In my book the code is finished. IBM introduced high memory for stuff such as DB2, which could use this high memory.
Now does the code contain bugs, possible. But we need to have proper debug data for that.
Roderick
--- End quote ---
I thought it was introduced in WarpServer and at first only 2GB's before being extended to 3GB's.
As for bugs, seems most of the kernel fixes since IBM left development have been high memory related, as well as the undocumented problems with parts of the OS/2 API not working with high memory, see os2safe.h for the current list. Many were found the hard way when we started using high memory for Mozilla.
It is easy to believe there are other bugs somewhere. Even Windows 32bit discouraged using more then 2GB's of address space, though I believe mostly due to buggy device drivers using signed ints
Edit: I'll also add that Arca Noae has decided on a 1536 default for VAL. When I asked Lewis about it, he just commented that they figured it was safer. Can't remember if he said it was from experience or just due to caution.
OS4User:
--- Quote from: Dave Yeo on November 20, 2021, 07:56:14 pm ---4GB's of address space minus PCI memory address space (including video memory) equals 3.2Mb's of address space in my case, and then minus kernel address space, things like the JFS cache.
--- End quote ---
Dave, you've mixed all together :) . Yes, you can see 3.2GB of total RAM accessible to system (even if 4 GB of SIMM modules are installed) because of PCI dev, BIOSes, APICs, HPET and video adapter (may be something else). But this is physical mem. Kernel operates by 32 bit phys address only - that is why 4GB can be addressed and no more.
All virtual mem in summary is always 4GB in spite of how much physical mem you have.
Virtual memory is divided into tree parts:
- low (under 512M) (private and shared)
- hight (between 512M and VAL)(private and shared)
- system (between VAL and 4GB)
PDDs, FSDs, PSD, kernel, loader, JFS cache and many other things are in system memory.
Use of system memory almost doesn't grow after boot.
System compensates lack of RAM by swap file.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version