QT5 simplebrowser

[Dariusz Piatkowski]

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.

I think you and Dave are in fact saying the same thing though, except that both of you are coming at this from a nearly 180deg opposite starting points.

For example, as Dave pointed out re: my JFS cache size experiments. Running with VIRTUALADDRESSLIMIT=3072 I could not enlarge my cache beyond the 64M that I initially started with. Going to something much larger, such as 256, 512 or my current 736M size required me to lower the VIRTUALADDRESSLIMIT setting in order to (I believe) free up the 'system' area.

So yes, if my machine has a total accessible memory space of 3.2G, and my VIRTUALADDRESSLIMIT=3072, I have very little room there to work with. Once I drop VIRTUALADDRESSLIMIT=2048 that opens up a boat load more space, which is how I can pull of a 736M JFS cache.

Therefore, there absolutely appears to be some limit (by design I believe) that won't allow the virual memory use to grow beyond what physical-(minus)-system total ends up being.

[OS4User]

I think you and Dave are in fact saying the same thing though, except that both of you are coming at this from a nearly 180deg opposite starting points.

No. It is not so.

Going to something much larger, such as 256, 512 or my current 736M size required me to lower the VIRTUALADDRESSLIMIT setting in order to (I believe) free up the 'system' area.

By lowering VAL you INCREASE system arena (where JFS cache is situated) and same time you DECREASE high mem.

So yes, if my machine has a total accessible memory space of 3.2G, and my VIRTUALADDRESSLIMIT=3072, I have very little room there to work with.

One more time  -  "total accessible memory space of 3.2G"  does not have any relation to VAL.
Even you have 512Mb of RAM installed, with VAL=3072 you will have 1GB system arena.

For ex.  most of kernel's objects are ALWAYS (in spite of installed RAM) situated at the very top of VIRT mem:  0xFFE7700 - FFFC0000h. And just a few of them  mapped into specific phys mem (lower 1Mb).

Therefore, there absolutely appears to be some limit (by design I believe) that won't allow the virual memory use to grow beyond what physical-(minus)-system total ends up being.

It only appears that  ALL virt mem cannot be bigger than 4GB.

[Dariusz Piatkowski]

...
One more time  -  "total accessible memory space of 3.2G"  does not have any relation to VAL.
Even you have 512Mb of RAM installed, with VAL=3072 you will have 1GB system arena.

For ex.  most of kernel's objects are ALWAYS (in spite of installed RAM) situated at the very top of VIRT mem:  0xFFE7700 - FFFC0000h. And just a few of them  mapped into specific phys mem (lower 1Mb).
...

Yes, and this very statement is the crux of it. The point I am making, and perhaps what Dave was trying to say as well, is that it is the VAL setting itself that controls how much of that accessbile memory space is actually available for non-system use.

Case in point, speaking for myself only although I suspect the greater part of our OS/2 fan-base may also be covered by this, the physical size of installed memory on my machine is 4G. What this means is that I am no longer focused on the hypothetical amount of process space I can support, and in case the physical memory runs out the appropriate contents will be shuffled off to the swap file in order to free up memory for the newly loaded process.

Instead, given that I have 3.2G of addressable physical memory visible to OS/2, I am focused on how that memory is being allocated by the kernel and of course how the user adjustable settings/controls impact this.

The undeniable result is that VIRTUALADDRESSLIMIT= setting dictates how much memory the OS/2 kernel will allocate towards it's "system" use, and by doing so make that amount of memory unavailable to the process side of it.

Seriously...the JFS cache size use-case is literally a "black and white" test here. Unless I allow the system to allocate LESS physical memory in support of the VIRTUALADDRESSLIMIT setting, I cannot use that memory to implement the sort of "system" controls I am telling my machine to utilize.

Whiel I think I understand how this work, I do find this to be counterintuitive, expecting that should a VAL be set sky-high I should in fact be able to request a 1G JFS cache, have the system successfully allocate that space and accordingly pare-back the total process space memory available. Clearly that is not what happens.

[Dave Yeo]

I think the real memory and address space just happen to correspond with 4GB's of ram installed. If I removed some DIMM's to only have 2GB's of ram, there would still be 3.2 GB's of address space available to OS/2, system and program, and perhaps 1.5-1.75 GB's of real memory (due to the integrated graphics using real memory) available before the system starts swapping. Lower VAL like Dariusz did for a bigger JFS cache and even less real memory available before swapping.
BTW, the lower 1GB of address space is half kernel memory as 16 bit programs (and 16 bit kernel code) can only access 1GB of virtual memory, 16 MB address space, so the upper half of the lower 1GB is kernel, device drivers and such. 16 bit DLL's and data needed by them also have to go into the lower 1GB of address space.
The i386 can actually use something like 2TB of virtual memory and in theory, if internally using 64 bit variables, we could have 99 DOS sessions, each, using DPMS, allocating a GB of ram. Lots of swapping and the CPU's page tables might run out unless using 1MB (or was that 4MB) pages instead of the current 4kb page size.

[OS4User]

Unless I allow the system to allocate LESS physical memory in support of the VIRTUALADDRESSLIMIT setting, I cannot use that memory to implement the sort of "system" controls I am telling my machine to utilize.

Kernel always use ALL available PHYS mem (reported by BIOS). There is no way to influence this.

(OS/2 kernel has a bug and cannot operate with some specific regions of RAM and loader from Dixie is able to hide them from the kernel - but this is totally different story.)

Setting VAL you control VIRT mem layout only (not PHYS). You can use http://os2.snc.ru/product-SystemLoad.html to see the layout.

Whiel I think I understand how this work,

To have full understanding pls refer to Intel  doc and see how does work  phys to virt mapping.

I do find this to be counterintuitive, expecting that should a VAL be set sky-high I should in fact be able to request a 1G JFS cache

Of course, it is  counterintuitive. And I have no idea why you came to conclusion  to make VAL sky-high. As I said, JFS cache situated in System Arena. So to have more space for JFS cache you have to increase System Arena, is't it ? As I also said, System Arena is between VAL and 4GB - so you have to set VAL as low as possible (say 512) to have max size of System Arena (3.5GB).

[Dariusz Piatkowski]

...

I do find this to be counterintuitive, expecting that should a VAL be set sky-high I should in fact be able to request a 1G JFS cache

Of course, it is  counterintuitive. And I have no idea why you came to conclusion  to make VAL sky-high. As I said, JFS cache situated in System Arena. So to have more space for JFS cache you have to increase System Arena, is't it ? As I also said, System Arena is between VAL and 4GB - so you have to set VAL as low as possible (say 512) to have max size of System Arena (3.5GB).

We have gotten quite a bit off-topic here (given the QT5 & browser focus), but I will wrap up my input into the conversation by stating the following: VAL is intended to provide the additional memory footprint for applications that need the bigger "box" boundaries. My remark re: "counterintuitive" was meant to say that since that setting is there, it should NOT override and/or allow the system settings, such as the JFS cache for example, to be impacted by a user specified VAL value. After all, unless AND until I can successfully boot I have no chance to run an application that may in fact require such a large VAL in order to operate successfully.

The "why" this hasn't been resolved in the kernel/whatever logic is what I find to be "counterintutive".

Anyways, good discussion, I genuinely wish we had more of these kinds of topics in a "underneath the covers" type of a forum perhaps?

[roberto]

For NSPR_OS2_NO_HIRES_TIMER, it only matters whether it is set or not and only affects programs using NSPR4, mostly the Mozilla apps though IIRC, VirtualBox also uses it. Here's the code from nsprpub/pr/src/md/os2/os2inrval.c,

Sorry, when restoring a previous copy, had less colors defined in the resolution and gave me a better than expected result. But errors when the browser is closed are new values . With this modification
Saludos

[OS4User]

VAL is intended to provide the additional memory footprint for applications that need the bigger "box" boundaries.

VAL is intended to divide upper 3.5GB of virt address space between  high priv/shrd arena and system arena. Kernel takes VAL  value into consideration much earlier then FSD/PDD are loading (and JFS cache  allocating) - so no way to calculate  how big system arena has to be to accommodates all the parts of this puzzle. At the same time  nothing is preventing user to check how many free mem is in system arena after boot and adjust VAL accordingly to pass unused addresses from sys arena to high priv/shrd arena.