OS/2, eCS & ArcaOS - Technical > Web applications

QT5 simplebrowser

<< < (43/44) > >>

Dariusz Piatkowski:

--- Quote from: OS4User on November 20, 2021, 08:55:36 pm ---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.

--- End quote ---

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:

--- Quote from: Dariusz Piatkowski on November 20, 2021, 09:35:43 pm ---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.

--- End quote ---

:) No. It is not so.


--- Quote from: Dariusz Piatkowski on November 20, 2021, 09:35:43 pm ---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.

--- End quote ---

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


--- Quote from: Dariusz Piatkowski on November 20, 2021, 09:35:43 pm ---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.

--- End quote ---

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).


--- Quote from: Dariusz Piatkowski on November 20, 2021, 09:35:43 pm ---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.

--- End quote ---

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

Dariusz Piatkowski:

--- Quote from: OS4User on November 20, 2021, 10:15:40 pm ---...
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).
...

--- End quote ---

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:

--- Quote from: Dariusz Piatkowski on November 21, 2021, 12:18:51 am ---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.

--- End quote ---

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.


--- Quote from: Dariusz Piatkowski on November 21, 2021, 12:18:51 am ---Whiel I think I understand how this work,

--- End quote ---

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


--- Quote from: Dariusz Piatkowski on November 21, 2021, 12:18:51 am ---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

--- End quote ---

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).

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version