I have already understood Page Boundary, I learn quickly. I understand that Remy's 2944 are out of rank, and can be dangerous.
Thanks dave
Saludos
I guess it depends on how things are implemented, 2944=B80h, still a fairly round number, remembering that 80h is half of 100h.
Personally, I'd stick with the the recommended values. Could use Theseus to look closer.
Really this is just playing with numbers, the important thing is how much memory can actually be allocated and committed, and when it matters.
Well, just refresh me, a page is 4K, right ?
2944 is a multiple of 4 ( 4 * 736 ) or ( 64 * 46 )
When I use any of suggest values, my usable storage is always dropping to a low value, I did approach using 4k pages and this value was the one providing me with the maximum available storage.Hi Roberto,
If you use hex for virtualaddresslimit, you see the proper values end in 00, which is a page boundary.
3072=C00h
2816=B00h
2560=A00h
2304=900h
2048=800h
1792=700h
1536=600h
it is likely important to have a page boundary such as above.
Why do you use a MiB converted to hex (MiB value) to determine page boudary ?
I though a page is 4KiB, is it ?
1536 is MiB or 1572864 KiB ( 180000H ) - number of 4k pages in hex value
2944 -> 3014656 KiB ( 2E0000H ) - number of 4k pages in hex value
My use of page was probably not the best, apologies. For the i386, a page is 4KiB, an i686+ can also have 1MiB pages, not that it happens with OS/2.
OS/2 2.x allocates in 4KiB chunks, Warp allocates 64KiB chunks, but might only commit 4KiB, so probably better to use 64KiB's in your calculations.
I used the page boundary converted to hex as computers work in binary which more accurately are represented in hex. For certain things such as fixup tables, round hex numbers are better. I (and most of us) don't know how things are programmed in the kernel when it comes to high memory, so I was guessing that it only works with some numbers such as I listed.
The documentation is lacking, looking now, I can only find mention of VIRTUALADDRESSLIMT in the programming addendum under DosQuerySysInfo(), which is the function that mem uses to get most of its info, it says,
30 QSV_VIRTUALADDRESSLIMIT
Size of the user's address space in megabytes (that is, the value of the rounded VIRTUALADDRESSLIMIT)
Not much to go on, besides what others say. I did test your setting of VIRTUALADDRESSLIMIT=2944,
Seems to work, From Theseus, General System Information,"QSV_VIRTUALADDRESSLIMIT = b8000000"
OS/2 is able to use up to near 3.5GiB, could you get a value near this one using your settings ?
I tried several setting in respect of 4k pages and I could see that using 3072, the system rounded the storage to a lower value. I think (should be confirmed) that OS/2 is calculating the value to satisfy boundaries pages and despite the given value, it changes it to satisfy its architecture and the mem output is the value OS/2 determined to be correct according the given limit.
It is correct ?
I'm interested to get more details about how it works here.
As I said, I'm not really sure if my understanding is correct. The documentation is clear that the values returned by DosQuerySysInfo() is only advisory,
19 QSV_TOTAVAILMEM
Maximum number of bytes of memory that can be allocated by all processes in the system. This number is advisory and is not guaranteed, since system conditions change constantly.
With similar for the others.
I'm really not sure how much some of these numbers such as available virtual memory matter as well as how accurate they are. Changing the size/location of the swap file shouldn't matter, yet it changes what the system reports, weird.
I guess what matters is getting out of memory errors and when it happens.
Building Qt5, I got failures of cpp.exe not being able to allocate enough memory, reboot fixed, I also got popups about not enough resources to start make (lots of make processes run during the build), also fixed by a reboot, and I also saw my swap file grow, seems I used more memory then the 3.2 GiB accessible to my system.
Unluckily, a lot of the times, the system just locks up when memory gets low. Probably depends on the type of memory as things get funky when shared gets low. Builds do fail in similar ways, locks up and eventually have to reboot to get rid of the zombie process, reducing the number of jobs that make runs usually fixes that issue, as well as having VIRTUALADDRESSLIMIT set to 3072, which at one point wlink would complain and fail due to not enough spill memory (address range) without that setting.
Not an expert and I'm sure I've got some stuff wrong.