Document revision date: 15 July 2002 | |
Previous | Contents | Index |
Page-file sections are used to store temporary data in private or global (shared) sections of memory. In releases prior to OpenVMS Alpha Version 7.3, the maximum amount of data that could be backed up to page files was 32 GB per process (4 process page files, each 8 GB) and 504 GB per system (63 page files, each 8 GB).
With OpenVMS Alpha Version 7.3, the previous limits for page-file sections were extended significantly to take advantage of larger physical memory. Now images that use 64-bit addressing can map and access an amount of dynamic virtual memory that is larger than the amount of physical memory available on the system.
With this design, if a process requires additional page-file space, page files can be allocated dynamically. Space is no longer reserved in a distinct page file, and pages are no longer bound to an initially assigned page file. Instead, if modified pages must be written back, they are written to the best available page file.
Each page or swap file can hold approximately 16 million pages (128 GB), and up to 254 page or swap files can be installed. Files larger than 128 GB are installed as multiple files.
Note the following DCL command display changes and system parameter changes as a result of the larger page-file section design:
$ SHOW MEMORY/FILES System Memory Resources on 22-MAY-2000 19:04:19.67 Swap File Usage (8KB pages): Index (1) Free Size DISK$ALPHASYS:[SYS48.SYSEXE]SWAPFILE.SYS 1 904 904 DISK$SWAP:[SYS48.SYSEXE]SWAPFILE.SYS;1 2 1048 1048 Total size of all swap files: 1952 Paging File Usage (8KB pages): Index (2) Free Size DISK$PAGE:[SYS48.SYSEXE]PAGEFILE.SYS;1 253 16888 16888 DISK$ALPHASYS:[SYS48.SYSEXE]PAGEFILE.SYS 254 16888 16888 Total size of all paging files: 33776 Total committed paging file usage: (3) 1964 |
$ SHOW MEMORY/FILES/FULL System Memory Resources on 22-MAY-2000 18:47:10.21 Swap File Usage (8KB pages): Index Free Size DISK$ALPHASYS:[SYS48.SYSEXE]SWAPFILE.SYS 1 904 904 Paging File Usage (8KB pages): Index Free Size DISK$ALPHASYS:[SYS48.SYSEXE]PAGEFILE.SYS 254 16888 16888 Total committed paging file usage: 1960 |
This chapter describes the use of system services and run-time routines that VAX systems use to manage memory. It contains the following sections:
Section 13.1 describes the page size on VAX systems.
Section 13.2 describes the layout of virtual address space.
Section 13.3 describes extended addressing enhancements on selected VAX systems.
Section 13.4 describes the three levels of memory allocation routines.
Section 13.5 discusses how to use system services to add virtual
address space, adjust working sets, control process swapping, and
create and manage sections.
13.1 Virtual Page Size
To facilitate memory protection and mapping, the virtual addresss space
on VAX systems is subdivided into segments of 512-byte sizes called
pages. (On Alpha systems, memory page sizes are much
larger and vary from system to system. See Chapter 12 for
information about Alpha page sizes.) Versions of system services and
run-time library routines that accept page-count values as arguments
interpret these arguments in 512-byte quantities. Services and routines
automatically round the specified addresses to page boundaries.
13.2 Virtual Address Space
The initial size of a process's virtual address space depends on the size of the image being executed. The virtual address space of an executing program consists of the following three regions:
A summary of these regions appears in Figure 13-1.
Figure 13-1 Virtual Address Overview on VAX Systems
The memory management routines map and control the relationship between physical memory and the virtual address space of a process. These activities are, for the most part, transparent to you and your programs. In some cases, however, you can make a program more efficient by explicitly controlling its virtual memory usage.
The maximum size to which a process can increase its address space is controlled by the system parameter VIRTUALPAGECNT.
Using memory management system services, a process can add a specified number of pages to the end of either the program region or the control region. Adding pages to the program region provides the process with additional space for image execution, for example, for the dynamic creation of tables or data areas. Adding pages to the control region increases the size of the user stack. As new pages are referenced, the stack is automatically expanded, as shown in Figure 13-2. (By using the STACK= option in a linker options file, you can also expand the user stack when you link the image.)
Figure 13-2 illustrates the layout of a process's virtual memory. The initial size of a process's virtual address space depends on the size of the image being executed.
Figure 13-2 Layout of VAX Process Virtual Address Space
Selected VAX systems have extended addressing (XA) as part of the memory management subsystem. Extended addressing enhancement is supported on the VAX 6000 Model 600, VAX 7000 Model 600, and VAX 10000 Model 600 systems. Extended addressing contains the following two major enhancements that affect system images, system integrated products (SIPs), privileged layered products (LPs), and device drivers:
Extended physical addressing increases the size of a physical address from 30 bits to 32 bits. This increases the capacity for physical memory from 512 MB to 3.5 GB as shown in Figure 13-3. The 512 MB is still reserved for I/O and adapter space.
Figure 13-3 Physical Address Space for VAX Systems with XPA
Extended virtual addressing (XVA) increases the size of the virtual page number field in the format of a system space address from 21 bits to 22 bits. The region of system virtual address space, known as the reserved region or S1 space, is appended to the existing region of system virtual address space known as S0 space, thereby creating a single region of system space. As a result, the system virtual address space increases from 1 GB to 2 GB as shown in Figure 13-4.
Figure 13-4 Virtual Address Space for VAX Systems with XVA
As shown in Figure 13-3, extended addressing increases the maximum
physical address space supported by VAX systems from 1 GB to 4 GB. This
is accomplished by expanding the page frame number (PFN) field in a
page table entry (PTE) from 21 bits to 23 bits, and implementing
changes in the memory management arrays that are indexed by PFN. Both
the process page table entry and system page table entry are changed.
13.4 Levels of Memory Allocation Routines
Sophisticated software systems must often create and manage complex data structures. In these systems, the size and number of elements are not always known in advance. You can tailor the memory allocation for these elements by using dynamic memory allocation. By managing the memory allocation, you can avoid allocating fixed tables that may be too large or too small for your program. Managing memory directly can improve program efficiency. By allowing you to allocate specific amounts of memory, the operating system provides a hierarchy of routines and services for memory management. Memory allocation and deallocation routines allow you to allocate and free storage within the virtual address space available to your process.
There are three levels of memory allocation routines:
SYS$EXPREG (Expand Region)
SYS$CRETVA (Create Virtual Address Space)
SYS$DELTVA (Delete Virtual Address Space)
SYS$CRMPSC (Create and Map Section)
SYS$MGBLSC (Map Global Section)
SYS$DGBLSC (Delete Global Section)
LIB$CREATE_VM_ZONE
LIB$CREATE_USER_VM_ZONE
LIB$DELETE_VM_ZONE
LIB$FIND_VM_ZONE
LIB$RESET_VM_ZONE
LIB$SHOW_VM_ZONE
LIB$VERIFY_VM_ZONE
Modular application programs can call routines at any or all levels of the hierarchy, depending on the kinds of services the application program needs. You must observe the following basic rule when using multiple levels of the hierarchy:
Memory that is allocated by an allocation routine at one level of the hierarchy must be freed by calling a deallocation routine at the same level of the hierarchy. For example, if you allocated a page of memory by calling LIB$GET_VM_PAGE, you can free it only by calling LIB$FREE_VM_PAGE.
Figure 13-5 shows the three levels of memory allocation routines.
Figure 13-5 Hierarchy of VAX Memory Management Routines
For information about using memory management RTLs, see Chapter 14.
13.5 Using System Services for Memory Allocation
This section describes how to use system services to perform the following tasks:
The system services allow you to add address space anywhere within the process's program region (P0) or control region (P1). To add address space at the end of P0 or P1, use the Expand Program/Control Region (SYS$EXPREG) system service. SYS$EXPREG optionally returns the range of virtual addresses for the new pages. To add address space in other portions of P0 or P1, use SYS$CRETVA.
The format for SYS$EXPREG is as follows:
SYS$EXPREG (pagcnt ,[retadr] ,[acmode] ,[region]) |
Specifying the Number of Pages
Use the pagcnt argument to specify the number of pages to add to the end of the region. The range of addresses where the new pages are added is returned in retadr.
Use the acmode argument to specify the access to be assigned to the newly created pages.
Use the region argument to specify whether to add the pages to the end of the P0 or P1 region. This argument is optional.
To deallocate pages allocated with SYS$EXPREG, use SYS$DELTVA.
The following example illustrates how to add 4 pages to the program region of a process by writing a call to the SYS$EXPREG system service:
#include <stdio.h> #include <ssdef.h> main() { unsigned int status, retadr[1],pagcnt=4, region=0; /* Add 4 pages to P0 space */ status = SYS$EXPREG( pagcnt, &retadr, 0, region); if (( status & 1) != 1) LIB$SIGNAL( status ); else printf("Starting address: %d Ending address: %d\n", retadr.lower,retadr.upper); } |
The value 0 is passed in the region argument to specify that the pages are to be added to the program region. To add the same number of pages to the control region, you would specify REGION=#1.
Note that the region argument to SYS$EXPREG is optional; if it is not specified, the pages are added to or deleted from the program region by default.
The SYS$EXPREG service can add pages only to the end of a particular region. When you need to add pages to the middle of these regions, you can use the Create Virtual Address Space (SYS$CRETVA) system service. Likewise, when you need to delete pages created by either SYS$EXPREG or SYS$CRETVA, you can use the Delete Virtual Address Space (SYS$DELTVA) system service. For example, if you have used the SYS$EXPREG service twice to add pages to the program region and want to delete the first range of pages but not the second, you could use the SYS$DELTVA system service, as shown in the following example:
#include <stdio.h> #include <ssdef.h> struct { unsigned int lower, upper; }retadr1, retadr2, retadr3; main() { unsigned int status, pagcnt=4, region=0; /* Add 4 pages to P0 space */ status = SYS$EXPREG( pagcnt, &retadr1, 0, region); if (( status & 1) != 1) LIB$SIGNAL( status ); else printf("Starting address: %d ending address: %d\n", retadr1.lower,retadr1.upper); /* Add 3 more pages to P0 space */ pagcnt = 3; status = SYS$EXPREG( pagcnt, &retadr2, 0, region); if (( status & 1) != 1) LIB$SIGNAL( status ); else printf("Starting address: %d ending address: %d\n", retadr2.lower,retadr2.upper); /* Delete original allocation */ status = SYS$DELTVA( &retadr1, &retadr3, 0 ); if (( status & 1) != 1) LIB$SIGNAL( status ); else printf("Starting address: %d ending address: %d\n", retadr1.lower,retadr1.upper); } |
In this example, the first call to SYS$EXPREG adds 4 pages to the program region; the virtual addresses of the created pages are returned in the 2-longword array at retadr1. The second call adds 3 pages and returns the addresses at retadr2. The call to SYS$DELTVA deletes the first 4 pages that were added.
Be aware that using SYS$CRETVA presents some risk because it can delete pages that already exist if those pages are not owned by a more privileged access mode. Further, if those pages are deleted, no notification is sent. Therefore, unless you have complete control over an entire system, use SYS$EXPREG or the RTL routines to allocate address space. |
When the SYS$EXPREG system service adds pages to a region, it adds them in the normal direction of growth for the region. The return address array, if requested, indicates the order in which the pages were added. For example:
The addresses returned indicate the first byte in the first page that was added or deleted and the last byte in the last page that was added or deleted.
When input address arrays are specified for the Create and Delete Virtual Address Space (SYS$CRETVA and SYS$DELTVA, respectively) system services, these services add or delete pages beginning with the address specified in the first longword and ending with the address specified in the second longword.
The operating system always adjusts the starting and ending virtual addresses up or down to fit page boundaries. |
The order in which the pages are added or deleted does not have to be in the normal direction of growth for the region. Moreover, because these services add or delete only whole pages, they ignore the low-order 9 bits of the specified virtual address (the low-order 9 bits contain the byte offset within the page). The virtual addresses returned indicate the byte offsets.
Table 13-1 shows some sample virtual addresses in hexadecimal that may be specified as input to SYS$CRETVA or SYS$DELTVA and shows the return address arrays if all pages are successfully added or deleted.
Input Array | Output Array | ||||
---|---|---|---|---|---|
Start | End | Region | Start | End | Number of Pages |
1010 | 1670 | P0 | 1000 | 17FF | 4 |
1450 | 1451 | P0 | 1400 | 15FF | 1 |
1200 | 1000 | P0 | 1000 | 13FF | 2 |
1450 | 1450 | P0 | 1400 | 15FF | 1 |
7FFEC010 | 7FFEC010 | P1 | 7FFEC1FF | 7FFEC000 | 1 |
7FFEC010 | 7FFEBCA0 | P1 | 7FFEC1FF | 7FFEBC00 | 3 |
Note that if the input virtual addresses are the same, as in the fourth and fifth items in Table 13-1, a single page is added or deleted. The return address array indicates that the page was added or deleted in the normal direction of growth for the region.
Previous | Next | Contents | Index |
privacy and legal statement | ||
5841PRO_041.HTML |