Question about output of `SHOW MEMORY`

[dmjb]

I'm running OpenVMS V9.2-2 with Update 2 on top of KVM. 8192MB of memory is allocated to the virtual machine. If I run `SHOW MEMORY`, I get the following output:

Code: Select all

$ SHOW MEMORY
              System Memory Resources on 18-JUN-2024 18:57:21.22

Physical Memory Usage (pages):     Total        Free      In Use    Modified
  Main Memory (7.74GB)           1015570      862181      151275        2114

Extended File Cache  (Time of last reset: 18-JUN-2024 18:28:25.00)
 Allocated (MBytes)            537.07    Maximum size (MBytes)          3967.07
 Free (MBytes)                   0.10    Minimum size (MBytes)             3.12
 In use (MBytes)               536.96    Percentage Read I/Os                79%
 Read hit rate                     77%   Write hit rate                       0%
 Read I/O count                 55679    Write I/O count                  14647
 Read hit count                 42888    Write hit count                      0
 Reads bypassing cache             29    Writes bypassing cache               3
 Files cached open                242    Files cached closed                707
 Vols in Full XFC mode              0    Vols in VIOC Compatible mode         2
 Vols in No Caching mode            0    Vols in Perm. No Caching mode        0

Granularity Hint Regions (pages):   Total        Free      In Use    Released
  S0 Execlet data                    2048        1726         322           0
  S0 Executive data                  4608          51        4557           0
  S0 Executive RO data               1024         832         192           0
  S0 Resident image code             3072        2989          83           0
  S0 Resident image data              512         512           0           0
  S0 Resident RO image data          1024        1024           0           0
  S2 Execlet code                    4096        1498        2598           0
  S2 Execlet data                    4096        4096           0           0
  S2 Executive data                  1024           0        1024           0
  S2 Resident image code             4096        1509        2587           0
  S2 Resident image data              512         512           0           0

Slot Usage (slots):                Total        Free    Resident     Swapped
  Process Entry Slots                912         895          17           0

Dynamic Memory Usage:              Total        Free      In Use     Largest
  Nonpaged Dynamic Memory (MB)     24.00       21.46        2.53       20.76
  USB Addressable Memory  (KB)   1024.00     1022.87        1.12     1022.87
  Paged Dynamic Memory    (MB)     11.47        6.59        4.88        6.58
  Lock Manager Dyn Memory (MB)      1.04        0.00        1.04
  S2 Dynamic Memory Usage (MB)      7.96        7.80        0.15        7.80

Buffer Object Usage (pages):                  In Use        Peak
  32-bit System Space Windows (S0/S1)              1           1
  64-bit System Space Windows (S2)                 0           0
  Physical pages locked by buffer objects          1           0

Memory Reservations (pages):       Group    Reserved      In Use        Type
  Total (0 bytes reserved)                         0           0

Paging File Usage (8KB pages):                 Index        Free        Size
  DISK$SYSDSK:[SYS0.SYSEXE]PAGEFILE.SYS;1                                       
                                                 254     1016336     1016336
  Total committed paging file usage:                                   17714

Of the physical pages in use, 67929 pages are permanently allocated to OpenVMS.

VMS recognizes slightly less than the 8GB allocated, but that's not what I am interested in. From what I understand, OpenVMS on x86 uses 4k pages (as with other x86 operating systems). If I take the total number of physical memory pages (1015570), multiply by 4096, and then divide by 1073741824 (i.e. one gigabyte) I get ~3.87GB, which is not correct.

If I read further, I notice `Paging File Usage (8KB pages)` near the bottom of the output. As far as I know, 8k was the page size on Alpha and IA64, and this made me wonder if SHOW MEMORY still assumed a 8192 byte page size instead of 4096 bytes. If I redo my earlier calculation using 8192 instead of 4096, I get the expected result of ~7.74GB.

I'm wondering if I am misunderstanding the information presented, or if the SHOW MEMORY command assumes that it is still dealing with 8192 byte pages on x86?

[arne_v]

I don't think it is just the SHOW MEM command.

$ write sys$output f$getsyi("PAGE_SIZE")
8192

[dmjb]

Is this documented anywhere? I checked the 9.2-2 release notes before posting in case it was a known issue, but I did not find anything related to 8k pages.

[arne_v]

I could not find anything either.

But I believe that even before x86-64 the recommended approach was to ask for page size at runtime, because even though
the hardware and VMS versions available used 8 KB pages then the documentation stated that it could change.

[anachronda]

From what I understand, OpenVMS on x86 uses 4k pages (as with other x86 operating systems).

I'm wondering if I am misunderstanding the information presented, or if the SHOW MEMORY command assumes that it is still dealing with 8192 byte pages on x86?

my understanding is that while the hardware uses 4k pages, vms handles them in pairs as if they were 8k pages.

[dgordon]

my understanding is that while the hardware uses 4k pages, vms handles them in pairs as if they were 8k pages.

This is correct. This choice was made to cut down on the number of places in the OS where we might have to look for page size assumptions. Using a pair to make 8k pages made the most sense (though it did introduce some other PFN-related fun.)

Future versions of the OS may use other page sizes in select areas of the system where it makes sense.

[dmjb]

Good to know, thanks for sharing.

[arne_v]

my understanding is that while the hardware uses 4k pages, vms handles them in pairs as if they were 8k pages.

This is correct. This choice was made to cut down on the number of places in the OS where we might have to look for page size assumptions. Using a pair to make 8k pages made the most sense (though it did introduce some other PFN-related fun.)

And for users as well.

I know that I should use GETSYI to get it, but:

$ sear [...]*.h,*.c,*.for,*.pas,*.bas page,size,8192 /match=and

still gave me 4 cases of:

#define PAGE_SIZE 8192

and one case of:

PAGE_SIZE = 8192;