![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Shared page tables are created and propagated to multiple processes by a cooperating set of system services. No special privileges or rights identifiers are required for a process or application to use shared page tables. The VMS$MEM_RESIDENT_USER rights identifier is required only to create a memory-resident global section. Processes that do not have this identifier can benefit from shared page tables (as long as certain mapping criteria prevail).
Similar to memory reserved for memory-resident global sections, memory for shared page tables must be deducted from the system's set of fluid pages. The Reserved Memory Registry allows for this deduction when a memory-resident global section is registered.
Table 4-1 highlights the physical memory requirements for private page tables and shared page tables that map to various sizes of global sections by various numbers of processes. This table illustrates the amount of physical memory saved systemwide through the use of shared page tables. For example, when 100 processes map to a 1 GB global section, 99 MB of physical memory are saved by mapping to the global section with shared page tables.
Overall system performance benefits from this physical memory savings because of the reduced contention for the physical memory system resource. Individual processes benefit from the reduction of working set usage by page table pages, thus allowing a process to keep more private code and data in physical memory.
Table 4-1 Page Table Size Requirements
Number of | Size of Global Section Mapping | 8MB 1GB 8GB 1TB Processes | PPT SHPT PPT SHPT PPT SHPT PPT SHPT ___________+___________________________________________________________________ 1 | 8KB 8KB 1MB 1MB 8MB 8MB 1GB 1GB 10 | 80KB 8KB 10MB 1MB 80MB 8MB 10GB 1GB 100 | 800KB 8KB 100MB 1MB 800MB 8MB 100GB 1GB 1000 | 8MB 8KB 1GB 1MB 8GB 8MB 1TB 1GB
To benefit from shared page tables, a process does not require any special privileges or rights identifiers. Only the creator of a memory-resident global section requires the rights identifier VMS$MEM_RESIDENT_USER. The creation of the memory-resident global section causes the creation of the shared page tables that map that global section unless the Reserved Memory Registry indicates that no shared page tables are required. At first glance, it may appear that there is a security risk inherent in allowing this greater level of data sharing. There is no security risk for the reasons described in this section.
An application or process that maps to a memory-resident global section with shared page tables must take the following steps:
A shared page table region can only map memory-resident global sections. An application can map more than one memory-resident global section into a shared page table region. The starting virtual address for global sections mapped into a shared page table region are always rounded to a page table page boundary. This prevents two distinct global sections from sharing the same page table page. Attempts to create virtual address space in a shared page table region with any other system service except those listed in Step 2 will fail.
Note
Processes can specify a non-shared page table region for mapping to a memory- resident global section with shared page tables. In this case, process private page tables are used to map to the global section.
The GBLPAGES system parameter defines the size of the global page table. The value stored in the parameter file is used at boot time to establish the initial size of the global page table.
As of OpenVMS Alpha Version 7.1, the system parameters GBLPAGES and GBLPAGFIL have been modified to become dynamic parameters. Users with the CMKRNL privilege can now change their effective values on the running system. Increasing the value of the GBLPAGES parameter at runtime allows the global page table to expand, on demand, up to the new maximum size. All the following conditions must be met for the global page table to expand or grow:
Because the global page table is mapped in 64-bit S2 space, which is a minimum of 6 GB, these conditions can be met by almost all systems. Only extremely memory-starved systems or systems with applications making extensive use of S2 virtual address space may make it impossible to grow the global page table on demand.
Because global pages are a system resource that also affects other tuning parameters, Digital recommends using AUTOGEN and rebooting systems in order to increase GBLPAGES. If a reboot is not possible for operational reasons, the parameter may be changed on the running system using the following commands:
$ RUN SYS$SYSTEM:SYSGEN SYSGEN> USE ACTIVE SYSGEN> SET GBLPAGES new_value SYSGEN> WRITE ACTIVE
The WRITE ACTIVE command requires the CMKRNL privilege.
The same commands also allow you to reduce the effective size of the global page table. The global page table is actually reduced and full pages are released to the system as fluid pages under the following conditions:
Reducing the active value of GBLPAGES below the number of currently used global pages does not affect currently used global pages. It only prevents the creation of additional global pages.
Increasing the active value of the GBLPAGFIL parameter always succeeds, up to the maximum positive integer value. As with GBLPAGES, reducing the value of GBLPAGFIL below the number of global pages that may be paged against the system's pagefile has no effect on these pages. Doing so simply prevents the creation of additional global pagefile sections.
Note that an increase of GBLPAGFIL may also require that additional pagefile space be satisfied by installing an additional pagefile.
The Reserved Memory Registry through its interface within the SYSMAN utility allows an OpenVMS Alpha system to be configured with large amounts of memory set aside for use within memory-resident sections and by other privileged applications. The Reserved Memory Registry also allows an OpenVMS system to be properly tuned through the AUTOGEN utility, taking into account the preallocated reserved memory.
With the Reserved Memory Registry you can:
The Reserved Memory Registry includes the ability to specify that the pre-allocated pages are to be zeroed during the booting of the system. This option reduces the time required to create the memory-resident global demand-zero section.
Another option within the Reserved Memory Registry is to include the size of the page tables required to map to the memory-resident global section in the reserved memory. If this option is specified and the reserved memory is being used for a memory-resident global section, the memory-resident global section is created with shared page tables.
OpenVMS provides a mechanism to reserve non-fluid memory for use within a memory-resident global demand-zero section. The reserved memory may either be simply a deduction from the system's non-fluid memory size or also pre-allocated as contiguous, aligned physical pages.
Using the Reserved Memory Registry ensures that AUTOGEN tunes the system properly to not include memory-resident section pages in its calculation of the system's fluid page count. AUTOGEN sizes the system pagefile, number of processes and working set maximum size based on the system's fluid page count. A system can experience severe performance problems if AUTOGEN adjusts parameters based upon a fluid page count that does not account for the physical memory that is permanently reserved for some other purpose.
Using the Reserved Memory Registry also ensures that contiguous, aligned memory is available for memory-resident sections when the allocate option is used.
Note
Although this section describes how to use the reserved memory registry for global sections, this feature can be used for other privileged applications.
Consumers of reserved, non-fluid memory enter the characteristics of the memory into a data file that is read during the system initialization (boot-time). The mechanics of manipulating the data file are similar to SYS$LOADABLE_IMAGES:VMS$SYSTEM_IMAGES.DATA (indicates installation-specific executive loaded images).
This file is called:
SYS$SYSTEM:VMS$RESERVED_MEMORY.DATA
The file is maintained by the SYSMAN utility (as is the executive loaded image data file).
The Reserved Memory Registry file, VMS$RESERVED_MEMORY.DATA, is read by the AUTOGEN feedback mechanism and factors into the setting of the system's fluid page count. AUTOGEN sizes the system pagefile, number of processes and working set maximum size based on the system's fluid page count.
You add an entry to the data file by using the SYSMAN utility. The SYSMAN command is as follows:
SYSMAN RESERVED_MEMORY ADD gs_name -
/GROUP = n -
/SIZE = {size of reserved memory, unit: MB} -
/[NO]ALLOCATE -
/[NO]ZERO -
/[NO]PAGE_TABLES
1. size >= 4 Mbytes: physically aligned on a 4 Mbyte boundary 2. size < 4 Mbytes: physically aligned on a 512 Kbyte boundary
You can remove a reserved memory entry by issuing the following SYSMAN command:
SYSMAN RESERVED_MEMORY REMOVE gs_name /GROUP = n
The specified gs_name is the name of the memory-resident section associated with the entry being removed from the Reserved Memory Registry. A name must be specified.
The value n specified by the /GROUP qualifier is the UIC group number (in octal) associated with the memory-resident section being removed. The /GROUP qualifier must be specified if the memory-resident global section is a group global section. The /GROUP qualifier must not be specified if the memory-resident global section is a system global section.
If page tables are reserved for the named memory-resident global section, the additional reserved memory is also removed.
The REMOVE command only removes entries from the Reserved Memory Registry data file, it does not affect memory within the running system.
During system initialization the VMS$RESERVED_MEMORY.DATA data file is read.
For each entry in the data file, the number of megabytes is deducted from the system's fluid page count for this memory- resident global section as specified by the /SIZE qualifier on the RESERVED_MEMORY ADD command. If /PAGE_TABLES was specified, the amount of memory required for the shared page tables mapping the memory-resident global section is deducted from the system's fluid page count as well.
If /ALLOCATE was specified on the RESERVED_MEMORY ADD command, a contiguous chunk of physical pages is also allocated and set aside for the memory-resident global section. If /PAGE_TABLES was specified, an additional contiguous chunk of physical pages is allocated and set aside for the shared page tables. The pages have a physical alignment appropriate to use the largest granularity hint factor for the given sized chunk. If /ZERO was specified, the pages are zeroed during system initialization or when the system is idle. If /ZERO was not specified or if /NOZERO was specified, the pages are zeroed at the time the memory-resident global section is created.
If the system parameter STARTUP_P1 is set to MIN entries in the Reserved Memory Registry entries are ignored, and memory is not reserved.
If errors are encountered during system initialization while processing the Reserved Memory Registry data file, with reserving system fluid pages, or with allocating contiguous, aligned physical pages, a n error message is issued to the console and the system continues to boot.
In the running system, you can free reserved memory by issuing the following SYSMAN command:
SYSMAN RESERVED_MEMORY FREE gs_name /GROUP = n
The specified gs_name is the name of the memory-resident section associated with the entry being freed from the Reserved Memory Registry. A name must be specified.
The value n specified by the /GROUP qualifier is the UIC group number (in octal) associated with the memory-resident section being freed. The /GROUP qualifier must be specified if the memory-resident global section is a group global section. The /GROUP qualifier must not be specified if the memory-resident global section is a system global section.
If contiguous, aligned physical pages were not pre-allocated during system initialization for this global section, the reserved memory is simply added to the system's fluid page count. Otherwise the physical pages are deallocated onto the system's free or zeroed page list. The system's fluid page count is adjusted to include the deallocated pages.
If page tables are also reserved for the named memory- resident global section, the reserved memory for the shared page tables is also freed.
If the reserved memory is in use by the named memory-resident global section, the amount of reserved memory not currently in use is freed.
The RESERVED_MEMORY FREE command does not affect the Reserved Memory Registry data file contents, it only affects the memory within the running system.
Two different places hold reserved memory information, the Reserved Memory Registry data file and the Reserved Memory Registry in the running system created during system initialization based on the entries in the data file.
Different display mechanisms may be used depending on where the information about the reserved memory originates.
There are three mechanisms for displaying the Reserved Memory Registry within the running system, SYSMAN, the DCL SHOW MEMORY command and SDA.
SYSMAN RESERVED_MEMORY SHOW gs_name /GROUP = n
The system services SYS$CREATE_GDZRO and SYS$CRMPSC_GDZRO_64 call internal kernel mode OpenVMS Alpha routines to use the reserved memory registered in the Reserved Memory Registry.
The global section need not be registered in the Reserved Memory Registry. If the global section name is registered in the Reserved Memory Registry, the size of the global section need not exactly match the size of the reserved memory. If the global section is not registered or if /NOALLOCATE was specified when the global section was registered in the Reserved Memory Registry the fault option is used for the memory-resident global DZRO section. If the size is greater than the size of the reserved memory, the system service call to create the memory-resident global DZRO section fails if there are not enough additional fluid pages within the system.
If /ALLOCATE was specified when the global section was registered in the Reserved Memory Registry, the allocate option is used for the memory-resident global DZRO section. The size of the global section must be less than or equal to the size of the reserved, pre-allocated memory or the error SS$_MRES_PFNSMALL is returned by the system service call.
When a memory-resident global section is deleted, the physical pages used for that global section are deallocated to the free page list if contiguous, aligned physical pages were not pre-allocated for this global section. The system's fluid page count is adjusted only for those pages not reserved in the Reserved Memory Registry for this global section.
When a memory-resident global section is deleted, the physical pages used for that global section are returned to the Reserved Memory Registry if contiguous, aligned physical pages were pre-allocated for this global section. The physical pages are not deallocated to the free page list and are still reserved. No adjustment is made to the system's fluid page count.
Reserved memory may only be freed to the running system by using the RESERVED_MEMORY FREE command to the SYSMAN utility.
Note
Permanent global sections are deleted by calling SYS$DGBLSC and upon the last reference to the global section. Non-permanent global sections are simply deleted upon last reference to the global section.
The configuration of an OpenVMS Alpha application that uses memory-resident global sections performs the following steps:
This chapter summarizes changes to the RMS interface that support 64-bit addressing and enable you to use RMS to perform input and output operations to P2 or S2 space. You can take full advantage of these RMS enhancements by making only minor modifications to existing RMS code.
For complete information about RMS support for 64-bit addressing, see the OpenVMS Record Management Services Reference Manual.
The RMS user interface consists of a number of control data structures (FAB, RAB, NAM, XABs). These are linked together with 32-bit pointers and contain embedded pointers to I/O buffers and various user data buffers, including file name strings and item lists. RMS support for 64-bit addressable regions allows 64-bit addresses for the following user I/O buffers:
The prompt buffer pointed to by RAB$L_PBF is excluded because the terminal driver does not allow 64-bit addresses.
Specific enhancements to the RMS interface for 64-bit addressing are as follows:
The rest of the RMS interface currently is restricted to 32-bit pointers:
The RAB64, a new RMS user interface structure, is an extended RAB that can accommodate 64-bit buffer addresses. The RAB64 data structure consists of a 32-bit RAB structure followed by a 64-bit extension as shown below:
The RAB64 contains fields identical to all of the RAB fields except that field names have the RAB64 prefix instead of the RAB prefix. In addition, RAB64 has the following new fields in the extension:
| This new field... | ...is an extension of this field |
Description |
|---|---|---|
| RAB64$Q_CTX | RAB64$L_CTX | User context. This field is not used by RMS but is available to the user. The CTX field is often used to contain a pointer. For asynchronous I/O, it provides the user with the equivalent of an AST parameter. |
| RAB64$PQ_KBF | RAB64$L_KBF | Key buffer address containing the key value for random access (for $GET and $FIND). |
| RAB64$PQ_RBF | RAB64$L_RBF | Record buffer address (for $PUT, $UPDATE, and $WRITE). |
| RAB64$PQ_RHB | RAB64$L_RHB | Record header buffer address (fixed portion of VFC record format). |
| RAB64$Q_RSZ | RAB64$W_RSZ | Record buffer size. |
| RAB64$PQ_UBF | RAB64$L_UBF | User buffer address (for $GET and $READ). |
| RAB64$Q_USZ | RAB64$W_USZ | User buffer size. |
6467P002.HTM OSSG Documentation 22-NOV-1996 13:11:58.48
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.