Chapter 19. Processor storage management. IBM z/OS Version 2 Release 3
Reklama
Reklama
Chapter 19. Processor storage management
|
|
|
|
|
The system administers the use of processor storage (that is, central and expanded storage) and it directs the movement of virtual pages between auxiliary, expanded, and central storage in page size (4096 byte or 4 K-byte) blocks. It makes all addressable virtual storage in each address space and data space or hiperspace appear as central storage. Virtual pages necessary for program execution are kept in processor storage while: v The program references the pages frequently enough v Other programs do not need that same central storage.
The system performs the paging I/O necessary to transfer pages in and out of central storage and also provides DASD allocation and management for paging
I/O space on auxiliary storage.
The system assigns real frames upon request from a pool of available real frames, which associates virtual addresses with real addresses. A limit on the number of real frames that can be used by an address space is related to its virtual storage limits and its memory limits. For more information on these limits, see the
Chapter 11, “Virtual storage management,” on page 213 section and the z/OS MVS
Initialization and Tuning Guide. Frames are repossessed upon termination of use, when freed by a user, when a user is swapped-out, or when needed to replenish the available pool. While a virtual page occupies a real frame, the page is considered pageable unless specified otherwise as a system page that must be resident in central storage. The system also allocates virtual equals central (V=R) regions upon request by those programs that cannot tolerate dynamic relocation.
Such a region is allocated contiguously from a predefined area of central storage and is not pageable. Programs in this region do run in dynamic address translation
(DAT) mode, although real and virtual addresses are equivalent.
This chapter describes how you can: v Free the virtual storage in your address space and the virtual storage in any data space that you might have access to
– FREEMAIN and STORAGE RELEASE frees specific portions of virtual storage in address spaces.
– DSPSERV DELETE frees all of the virtual storage in a data space or hiperspace.
v Release the central and expanded storage that holds the data that your program has in virtual storage.
– PGRLSE or PGSER RELEASE releases specified portions of virtual storage contents of an address space.
– DSPSERV RELEASE releases specified portions of virtual storage contents of a data space or hiperspace.
v Request that a range of virtual storage pages be made read-only or be made modifiable.
– PGSER PROTECT allows the caller to request that a range of virtual storage pages be made read-only.
– PGSER UNPROTECT allows the caller to request that a range of virtual storage pages be made modifiable.
v Request that the system preload or page out central storage
© Copyright IBM Corp. 1988, 2017
359
– PGLOAD or PGSER LOAD loads specified virtual storage areas of an address space into central storage.
– PGOUT or PGSER OUT pages out specified virtual storage areas of an address space from central storage.
– DSPSERV LOAD loads specified virtual storage areas of a data space into central storage.
– DSPSERV OUT pages out specified virtual storage areas of a data space from central storage.
v Request that the system preload multiple pages on a page fault.
– REFPAT causes the system to preload pages according to a program's reference pattern. REFPAT is intended for numerically intensive programs.
Freeing virtual storage
All storage obtained for your program by GETMAIN, STORAGE OBTAIN, or
DSPSERV CREATE is automatically freed by the system when the job step terminates. Freeing storage in this manner requires no action on your part.
FREEMAIN or STORAGE RELEASE perform the equivalent of a page release for any resulting free page. The page is no longer available to the issuer. FREEMAIN can free a page that has been protected through the PGSER macro with the
PROTECT option. DSPSERV DELETE performs the same action for a data space that FREEMAIN and STORAGE RELEASE do for address space virtual storage except that for a data space or hiperspace, all of the storage is released.
Releasing storage
When your program is finished using an area of virtual storage, it can release the storage to make the central, expanded, or auxiliary storage that actually holds the data available for other uses. The decision to release the storage depends on the size of the storage and when the storage will be used again: v For large areas (over 100 pages, for example) that will not be used for five or more seconds of processor time, consider releasing the storage. If you do not release those pages after you are finished using them:
– Your program might be using central storage that could better be used for other purposes.
– Your program might have delays later when the system moves your pages from central storage to expanded or auxiliary storage.
v Generally, for smaller amounts of storage that will be used again in five seconds or less, do not release the storage.
Note that releasing storage does not free the virtual storage.
When releasing storage for an address space
, use PGRLSE or PGSER with the
RELEASE parameter. As shown in Figure 88 on page 361, if the specified addresses
are not on page boundaries, the low address is rounded up and the high address is rounded down; then, the pages contained between the addresses are released.
Note: PGRLSE, PGSER RELEASE, PGSER FREE with RELEASE=Y, and PGFREE
RELEASE=Y may ignore some or all of the pages in the input range and will not notify the caller if this was done.
Any pages in the input range that match any of the following conditions will be skipped, and processing continues with the next page in the range:
360
z/OS MVS Assembler Services Guide
v Storage is not allocated or all pages in a segment have not yet been referenced.
v
Page is in PSA, SQA or LSQA.
v Page is V=R. Effectively, it's fixed.
v Page is in BLDL, (E)PLPA, or (E)MLPA.
v Page has a page fix in progress or a nonzero FIX count.
v Pages with COMMIT in progress or with DISASSOCIATE in progress.
1 page
Released virtual storage address 1
(low)
Figure 88. Releasing Virtual Storage
address 2
(high)
When releasing storage for a data space or hiperspace
, use the DSPSERV
RELEASE macro to release the central, expanded or auxiliary storage that actually holds the data. PGSER RELEASE rejects any attempt to release protected storage, including storage that is dynamically protected through PGSER PROTECT. The starting address must be on a 4K-byte boundary and you can release data space storage only in increments of 4K bytes.
For both address spaces and data spaces, the virtual space remains, but its contents are discarded. When the using program can discard the contents of a large virtual area (one or more complete pages) and reuse the virtual space without the necessity of paging operations, the page release function may improve operating efficiency.
Protecting a range of virtual storage pages
The PROTECT option of PGSER makes a range of virtual storage pages read-only and helps to improve data integrity. The UNPROTECT option of PGSER makes a range of virtual storage pages modifiable. You can protect private storage both above and below 16 megabytes.
IBM recommends
that you use PGSER PROTECT only for full pages of storage on page boundaries. This usage avoids making other areas of storage read-only unintentionally. For instance, if you obtain a virtual storage area smaller than a page and then issue PGSER PROTECT, the entire page is made read-only, including the portion of the page that is not part of your storage area.
The system does not keep track of how many times a page has been protected or unprotected. One UNPROTECT cancels all PROTECTs for a given page.
Chapter 19. Processor storage management
361
Loading/paging out virtual storage areas
The PGLOAD, PGSER LOAD, and DSPSERV LOAD essentially provide a page-ahead function. By loading specified address space and data space areas into central storage, you can attempt to ensure that certain pages will be in central storage when needed. Page faults can still occur, however, because these pages may be paged out if not referenced soon enough.
Loading and paging for address spaces: With the page load function, you have the option of specifying that the contents of the virtual area is to remain intact or be released. If you specify RELEASE=Y with PGLOAD or PGSER LOAD, the current contents of entire virtual 4K pages to be brought in may be discarded and new real frames assigned without page-in operations; if you specify RELEASE=N, the contents are to remain intact and be used later. If you specify RELEASE=Y, the page release function will be performed before the page load function. That is, no page-in is needed for areas defining entire virtual pages since the contents of those pages are expendable.
Note: PGRLSE, PGSER RELEASE, PGSER FREE with RELEASE=Y, and PGFREE
RELEASE=Y may ignore some or all of the pages in the input range and will not notify the caller if this was done.
Any pages in the input range that match any of the following conditions will be skipped, and processing continues with the next page in the range: v Storage is not allocated or all pages in a segment have not yet been referenced.
v Page is in PSA, SQA or LSQA.
v Page is V=R. Effectively, it's fixed.
v Page is in BLDL, (E)PLPA, or (E)MLPA.
v Page has a page fix in progress or a nonzero FIX count.
v Pages with COMMIT in progress or with DISASSOCIATE in progress.
Loading and paging for data spaces: DSPSERV LOAD requests the starting address of the data space area to be loaded and the number of pages that the system is to load. It does not offer a RELEASE=Y or a RELEASE=N function.
PGOUT, PGSER OUT, and DSPSERV OUT initiate page-out operations for specified virtual areas that are in central storage. For address spaces, the real frames will be made available for reuse upon completion of the page-out operation unless you specify the KEEPREL parameter in the macro. An area that does not encompass one or more complete pages will be copied to auxiliary storage, but the real frames will not be freed. DSPSERV LOAD does not have the KEEPREL function.
The proper use of the page load and page out functions tend to decrease system overhead by helping the system keep pages currently in use, or soon to be in use, in central storage. An example of the misuse of the page load function is to load ten pages and then use only two.
362
z/OS MVS Assembler Services Guide
Virtual subarea list
The virtual subarea list (VSL) provides the basic input to the page service functions that use a 24-bit interface: PGLOAD, PGRLSE, and PGOUT. The list consists of one or more doubleword entries, with each entry describing an area of virtual storage.
The list must be non-pageable and contained in the address space of the subarea to be processed.
Each VSL entry has the following format. The flag bits that are described are the only flag bits that are intended for customer use.
Table 30. Format of a virtual subarea list (VSL) entry
Byte: 0 1 2 3 4 5 6 7
Contents:
Flags Start
Address
Flags End
Address + 1
Byte Contents
Byte 0
Flags:
Bit Meaning when set
1... ....
Bit 0 indicates that bytes 1 - 3 are a chain pointer to the next VSL entry to be processed; bytes 4-7 are ignored. This feature allows several parameter lists to be chained as a single logical parameter list.
Byte 1 Start address
: The address of the origin of the virtual area to be processed.
Byte 3
Flags
Bit Meaning when set
1... ....
Bit 0 indicates the last entry of the list. It is set in the last doubleword entry in the list.
.1.. ....
Bit 1 indicates that this entry is to be ignored.
...1 ....
Bit 3 indicates that a return code of 4 was issued from a page service function other than PGRLSE.
Byte 4 End address + 1
: The address of the byte immediately following the end of the virtual area.
Page service list (PSL)
The page services list provides the basic input to the page service function for the
PGSER macro. Specify 31-bit addresses in the PSL entries. Within a PSL entry, you can also nullify a service on a range of addresses by indicating that you do not want to perform the service for that range.
Each 12-byte PSL entry has the following form:
Bytes Meaning
0-3
4-7
Bit 0 of byte 0 must be 0. Each PSL entry specifies the range of addresses for which a service is to be performed or points to the first PSL entry in a new list of concatenated PSL entries that are to be processed.
Bit 0 of byte 4 must be 0. If bytes 0-3 contain the starting address, these bytes contain the address of the last byte for which the page service is to be performed. You do not need to do anything with bytes 4-7 if you supplied a pointer in bytes 0-3.
Chapter 19. Processor storage management
363
8
9-11
Flags set by the caller as follows. The flag bits that are described are the only flag bits intended for customer use.
Bit
0
Meaning
Set to 1 to indicate that this is the last PSL entry in a concatenation of PSL entries.
1
Set to 1 to indicate that no services are to be performed for the range of addresses specified.
2
Set to 1 to indicate that bytes 0-3 contain a pointer to the next PSL.
For IBM use only.
Defining the reference pattern (REFPAT)
The REFPAT macro allows a program to define a reference pattern for a specified area that the program is about to reference. Additionally, the program specifies how much data it wants the system to attempt to bring into central storage on a page fault. The system honors the request according to the availability of central storage. By bringing in more data at a time, the system takes fewer page faults; fewer page faults means possible improvement in performance.
Programs that benefit from REFPAT are those that reference amounts of data that are greater than one megabyte. The program should reference the data in a sequential manner, either forward or backward. In addition, if the program “skips over” certain areas, and these areas are of uniform size and are repeated at regular intervals, REFPAT might provide additional performance improvement. Although
REFPAT affects movement of pages from auxiliary and expanded storage, the greatest gain is for movement of pages from auxiliary storage.
There are two REFPAT services: v REFPAT INSTALL identifies the data area and the reference pattern, and specifies the number of bytes that the system is to try to bring into central storage at one time. These activities are called “defining the reference pattern”.
v REFPAT REMOVE removes the definition; it tells the system that the program has stopped using the reference pattern for the specified data area.
A program might have a number of different ways of referencing a particular area.
In this case, the program can issue multiple pairs of REFPAT INSTALL and
REFPAT REMOVE macros for that area.
Each pattern, as defined on REFPAT INSTALL, is associated with the task that represents the caller. A task can have up to 100 reference patterns defined for multiple data areas at one time, but cannot have more than one pattern defined for the same area. Other tasks can specify a different reference pattern for the same data area. REFPAT REMOVE removes the association between the pattern and the task.
The data area can be in the primary address space or in a data space owned by a task that was dispatched in the primary address space. If the data area is in a data space, identify the data space through its STOKEN. You received the STOKEN either from DSPSERV or from another program.
Although REFPAT can be used for data structures other than arrays, for simplicity, examples in this chapter use REFPAT for an array or part of an array.
364
z/OS MVS Assembler Services Guide
Reference pattern services for high-level language (HLL) and assembler language programs provide function similar to what REFPAT offers. For information about these services, see z/OS MVS Programming: Callable Services for High-Level Languages.
How does the system handle the data in an array?
To evaluate the performance advantage REFPAT offers, you need to understand how the system handles a range of data that a program references. Consider the
two-dimensional array in Figure 89 that is shown in row-major order and in order
of increasing addresses. This array has 1024 columns and 1024 rows and each
element is eight bytes in size. Each number in Figure 89 represents one element.
The size of the array is 1048576 elements for a total of 8388608 bytes. For simplicity, assume the array is aligned on a page boundary. Assume, also, that the array is not already in central storage. The program references each element in the array in a forward direction (that is, in order of increasing addresses) starting with the first element in the array.
1 2 3 4 5 6 7 8 9
. . . . . .
1025 1026 1027 1028
. . . . . . .
2049 2050 2051
. . . . . . . .
3073
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
1024
2048
3072
.
.
.
1048576
Figure 89. Example of using REFPAT with a Large Array
First, consider how the system brings data into central storage without using the information REFPAT provides. At the first reference of the array, the system takes a page fault and brings into central storage the page (of 4096 bytes) that contains the first element. After the program finishes processing the 512th element (4096 divided by 8) in the array, the system takes another page fault and brings in a second page. To provide the data for this program, the system takes two page faults for each row. The following linear representation shows the elements in the array and the page faults the system takes as the program processes through the array.
1st row 2nd row 3rd row
4th row last row
. . .
0 512th 1024th . . .
element element
1048576th element
. . .
1 page fault each 512 elements (1 page)
By bringing in one page at a time, the system takes 2048 page faults (8388608 divided by 4096), each page fault adding to the elapsed time of the program.
Chapter 19. Processor storage management
365
Suppose, through REFPAT, the system knew in advance that a program would be using the array in a consistently forward direction. The system could then assume that the program's use of the pages of the array would be sequential. To decrease the number of page faults, each time the program requested data that was not in central storage, the system could bring in more than one page at a time. Suppose the system brought the next 20 consecutive pages (81920 bytes) of the array into central storage on each page fault. In this case, the system takes not 2048 page faults, but 103 (8388608 divided by 81920=102.4). Page faults occur in the array as follows: rows 1-10 rows 11-20 rows 21-30 rows 31-40
. . .
rows 1021-1024
1 page fault each 10240 elements
The system brings in successive pages only to the end of the array.
Consider another way of referencing this same array. The program references the first twenty elements in each row, then skips over the last 1004 elements, and so forth through the array. REFPAT allows you to tell the system to bring in only the pages that contain the data in the first 20 columns of the array, and not the pages that contain only data in columns 21 through 1024. In this case, the reference pattern includes a repeating gap of 8032 bytes (1004 × 8) every 8192 bytes (1024 × 8).
The pattern looks like this: skip skip skip skip
. . .
1
21 elements ...
1025 1045 2049
2069
3073
3093
The grouping of consecutive bytes that the program references is called a reference
unit
. The grouping of consecutive bytes that the program skips over is called a
gap
. Reference units and gaps alternate throughout the data area. The reference pattern is as follows: v The reference unit is 20 elements in size — 160 consecutive bytes that the program references.
v The gap is 1004 elements in size — 8032 consecutive bytes that the program skips over.
Figure 90 on page 367 illustrates this reference pattern and shows the pages that
the system does not bring into central storage.
What pages does the system bring in when a gap exists?
When no gap exists, the system brings into central storage all the pages that contain the data in the range you specify on REFPAT. When there is a gap, the answer depends on the size of the gap, the size of the reference unit, and the alignment of reference units and gaps on page boundaries. The following examples illustrate those factors.
Example 1: The following illustration shows the 1024-by-1024 array of eight-byte elements, where the program references the first 20 elements in each row and skips
366
z/OS MVS Assembler Services Guide
over the next 1004 elements. The reference pattern, therefore, includes a reference unit of 160 bytes and a gap of 8032 bytes. The reference units begin on every other page boundary.
reference units
1st page
2nd page
3rd page
4th page
5th page
6th page
7th page
2048th page all pages brought into central storage
Figure 90. Illustration of a Reference Pattern with a Gap
Every other page of the data does not come into central storage; those pages contain only the “skipped over” data.
Example 2: The reference pattern includes a reference unit of 4800 bytes and a gap of 3392 bytes. The example assumes that the area to be referenced starts on a page boundary.
reference units
1st page
2nd page
3rd page
4th page
5th page
6th page
7th page
2048th page all pages brought into central storage
Because each page contains data that the program references, the system brings in all pages.
Example 3: The area to be referenced does not begin on a page boundary. The reference pattern includes a reference unit of 2000 bytes and a gap of 5000 bytes.
Because the reference pattern includes a gap, the first byte of the reference pattern must begin a reference unit, as the following illustration shows:
Start of reference pattern
1st page
2nd page
3rd page
4th page
5th page
6th page
7th page most pages brought into central storage
Because the gap is larger than 4095 bytes, some pages do not come into central storage. Notice that the system does not bring in the fifth page.
Summary of how the size of the gap affects the pages the system brings into central storage
: v If the gap is less than 4096 bytes, the system has to bring into central storage all pages of the array. (See Example 2.)
Chapter 19. Processor storage management
367
v If the gap is greater than 4095 bytes and less than 8192, the system might not have to bring in certain pages. Pages that contain only data in the gap are not brought in. (See Examples 1 and 3.) v If the gap is greater than 8191 bytes, the system definitely does not have to bring in certain pages that contain the gap.
Using the REFPAT macro
On the REFPAT macro, you tell the system: v The starting and ending addresses of the data area to be referenced v The reference pattern v The number of reference units the system is to bring into central storage on a page fault.
Specify the reference pattern carefully on REFPAT. If you identify a pattern and do not adhere to it, the system will have to work harder than if you had not issued
the macro. “Defining the reference pattern” on page 369 can help you define the
reference pattern.
The system will not process the REFPAT macro unless the values you specify can result in a performance gain for your program. To make sure the system processes the macro, ask the system to bring in more than three pages (that is, 12288 bytes)
on each page fault. “Choosing the number of bytes on a page fault” on page 370
can help you meet that requirement.
Identifying the data area and direction of reference
On the PSTART and PEND parameters, you specify the starting and ending addresses of the area to be referenced. If the reference is in a backward direction, the ending address will be smaller than the starting address.
PSTART identifies the first byte of the data area that the program references with the defined pattern; PEND identifies the last byte.
When a gap exists, define PSTART and PEND according to the following rules: v If direction is forward, PSTART must be the first byte (low-address end) of a reference unit; PEND can be any part of a reference unit or a gap.
v If direction is backward, PSTART must be the last byte (high-address end) of a reference unit; PEND can be any part of a reference unit or a gap.
Figure 91 illustrates a reference pattern that includes a reference unit of 2000 bytes
and a gap of 5000 bytes. When direction is forward, PSTART must be the beginning of a reference unit. PEND can be any part of a gap or reference unit.
forward direction
PSTART
PEND
1st page
2nd page
3rd page
4th page
5th page
6th page
7th page low address of range
Figure 91. Illustration of Forward Direction in a Reference Pattern
368
z/OS MVS Assembler Services Guide
Figure 92 illustrates the same reference pattern and the same area; however, the
direction is backward. Therefore, PSTART must be the last byte of a reference unit and PEND can be any part of a gap or reference unit.
PEND backward direction
PSTART
1st page
2nd page
3rd page
4th page
5th page
6th page
7th page high address of range
Figure 92. Illustration of Backward Direction in a Reference Pattern
If the data area is in a data space, use the STOKEN parameter to identify the data space. You received the STOKEN of the data space from another program or from the DSPSERV macro when you created the data space. STOKEN=0, the default, tells the system that the data is in the primary address space.
Defining the reference pattern
This information assumes that your program's reference pattern meets the basic
requirement of consistent direction. Figure 93 identifies tw o reference patterns that
characterize most of the reference patterns that REFPAT applies to. The marks on the line indicate referenced elements.
Pattern #1:
No uniform gap
0
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
4096
8192
12288
16384
...
20480
Characteristics of pattern:
- No uniform gap
- Reference in regular intervals (such as every element) or in irregular intervals
Pattern #2: Uniform gap
0
xxxxx
20 bytes
xxxxx
5020
5040 bytes bytes
xxxxx
10040
10060 bytes bytes
xxxxx
15060
15080 bytes bytes
...
20080 bytes
Characteristics of pattern:
- Gaps of uniform size
- Reference units, uniform in size, that occur in a repeating pattern
Figure 93. Two Typical Reference Patterns
How you define the reference pattern depends on whether your program's reference pattern is like Pattern #1 or Pattern #2.
v With Pattern #1 where no uniform gap exists , the program uses every element, every other element, or at least most elements on each page of array data. No
Chapter 19. Processor storage management
369
definable gap exists. Do not use REFPAT if the reference pattern is irregular and includes skipping over many areas larger than a page.
– The UNITSIZE parameter alone identifies the reference pattern. (Either omit the GAP parameter or take the default, GAP=0.) UNITSIZE indicates the number of bytes you want the system to use as a reference unit. Look at logical groupings of bytes, such as one row, a number of rows, or one element, if the elements are large in size. Or, you might choose to divide up the total area, bringing in all the data on a certain number of page faults.
– The UNITS parameter tells the system how many reference units to try to bring in on a page fault. For a reference pattern that begins on a page boundary and has no gap, the total number of bytes the system tries to bring into central storage at a time is the value on UNITSIZE times the number on
total number of bytes.
v With Pattern #2 where a uniform gap exists , you tell the system the sizes of reference units and gaps.
– UNITSIZE and GAP parameters identify the reference pattern. Pattern #2 in
Figure 93 on page 369 includes a reference unit of 20 bytes and a gap of 5000
bytes. Because the gap is greater than 4095, some pages of the array might not come into central storage.
– The UNITS parameter tells the system how many reference units to try to
come into central storage at one time.
Although the system brings in pages 4096 bytes at a time, you do not have to specify GAP, UNITS, and UNITSIZE values in increments of 4096.
Choosing the number of bytes on a page fault
An important consideration in using REFPAT is how many bytes to ask the system to bring in on a page fault. To determine this, you need to understand some factors that affect the performance of your program.
Pages do not stay in central storage if they are not referenced frequently enough and other programs need that central storage. The longer it takes for a program to begin referencing a page in central storage, the greater the chance that the page has been moved out to auxiliary storage before being referenced. When you tell the system how many bytes it should try to bring into central at one time, you have to consider the following:
1.
Contention for central storage
Your program contends for central storage along with all other submitted jobs.
The greater the size of central storage, the more bytes you can ask the system to bring in on a page fault. The system responds to REFPAT with as much of the data you request as possible, given the availability of central storage.
2.
Contention for processor time
Your program contends for the processor's attention along with all other submitted jobs. The more competition, the less the processor can do for your program and the smaller the number of bytes you should request.
3.
The elapsed time of processing one page of your data
How long it takes a program to process a page depends on the number of references per page and the elapsed time per reference. If your program uses only a small percentage of elements on a page and references them only once
370
z/OS MVS Assembler Services Guide
or twice, the program completes its use of pages quickly. If the processing of each referenced element includes processor-intensive operations or a time-intensive operation, such as I/O, the time the program takes to process a page gets longer.
Conditions might vary between the peak activity of the daytime period and the low activity of other periods. For example, you might be able to request a greater number in the middle of the night than during the day.
What if you specify too many bytes? What if you ask the system to bring in so many pages that, by the time your program needs to use some of those pages, they have left central storage? The answer is that the system will have to bring them in again. This action causes an extra page fault and extra system overhead and reduces the benefit of reference pattern services.
For example, suppose you ask the system to bring in 204800 bytes, or 50 pages, at a time. But, by the time your program begins referencing the data on the 30th page, the system has moved that page and the ones after it out of central storage.
(It moved them out because the program did not use them soon enough.) In this case, your program has lost the benefit of moving the last 21 pages in. Your program would get more benefit by requesting fewer than 30 pages.
What if you specify too few bytes? If you specify too small a number, the system will take more page faults than it needs to and you are not taking full advantage of reference pattern services.
For example, suppose you ask the system to bring in 40960 bytes (10 pages) at a time. Your program's use of each page is not time-intensive, meaning that the program finishes using the pages quickly. The program can request a number greater than 10 without causing additional page faults.
IBM recommends
that you use one of the following approaches, depending on whether you want to involve your system programmer in the decision.
v The first approach is the easier one. Choose a conservative number of bytes, around 81920 (20 pages), and run the program. Look for an improvement in the elapsed time. If you like the results, you might increase the number of bytes. If you continue to increase the number, at some point you will notice a diminishing improvement or even an increase in elapsed time. Do not ask for so much that your program or other programs suffer from degraded performance.
v
A second approach is for the program that needs very significant performance improvements — those programs that require amounts in excess of 50 pages. If you have such a program, you and your system programmer must examine the program's elapsed time, paging speeds, and processor execution times. In fact, the system programmer can tune the system with your program in mind and provide needed paging resources. See z/OS MVS Initialization and Tuning Guide for information on tuning the system.
REFPAT affects movement of pages from auxiliary and your system programmer will need the kind of information that the SMF Type 30 record provides. A Type
30 record reports counts of pages moved (between expanded and central and between auxiliary and central) in anticipation of your program's use of those pages. It also provides elapsed time values. Use this information to calculate rates of movement in determining whether to specify a very large number of bytes — for example, an amount greater than 204800 bytes (50 pages).
Chapter 19. Processor storage management
371
Examples of using REFPAT to define a reference pattern
To clarify the relationships between the UNITSIZE, UNITS, and GAP parameters, this information contains three examples of defining a reference pattern. So that you can compare the three examples with what the system does without information from REFPAT, the following REFPAT invocation approximates the system's normal paging operation:
REFPAT INSTALL,PSTART=. . .,PEND=. . .,UNITSIZE=4096,GAP=0,UNITS=1
Each time the system takes a page fault, it brings in 4096 bytes, the system's reference unit. It brings in one reference unit at a time.
Example 1: The program processes an array in a consistently forward direction from one reference unit to the next. The processing of each element is fairly simple. The program runs during the peak hours and many programs compete for processor time and central storage. A reasonable value to choose for the number of bytes to be brought into central storage on a page fault might be 80000 bytes (around 20 pages). A logical grouping of bytes (the UNITSIZE parameter) is 4000 bytes. The following REFPAT macro communicates this pattern to the system:
REFPAT INSTALL,PSTART=FIRSTB,PEND=LASTB,UNITSIZE=4000,GAP=0,UNITS=20
Example 2: The program performs the same process as in the first example, except the program references few elements on each page. The program runs during the night hours when contention for the processor and for central storage is light. In this case, a reasonable value to choose for the number of bytes to come into central storage on a page fault might be 200000 bytes (around 50 pages). UNITSIZE can be
4000 bytes and UNITS can be 500. The following REFPAT macro communicates this pattern:
REFPAT INSTALL,PSTART=FIRSTB,PEND=LASTB,UNITSIZE=4000,GAP=0,UNITS=500
Example 3: The program references in a consistently forward direction through the same large array as in the second example. The pattern of reference includes a gap.
The program references 8192 bytes, then skips the next 4096 bytes, references the next 8192 bytes, skips the next 4096 bytes, and so forth throughout the array. The program chooses to bring in data eight pages at a time. Because of the size of the gap and the placement of reference units and gaps on page boundaries, the system does not bring in the data in the gaps. The following illustration shows this reference pattern:
FIRSTB
LASTB
0 bytes
8192 bytes
12288 bytes
20480 bytes
24576 bytes
32768 bytes
36864 bytes
.
.
.
The following REFPAT macro reflects this reference pattern:
REFPAT INSTALL,PSTART=FIRSTB,PEND=LASTB,UNITSIZE=8192,GAP=4096,UNITS=4 where the system is to bring into central storage 32768 (4 × 8192) bytes on a page fault.
Removing the definition of the reference pattern
When a program is finished referencing the data area in the way you specified on the REFPAT INSTALL macro, use REFPAT REMOVE to tell the system to return to
372
z/OS MVS Assembler Services Guide
normal paging. On the PSTART and PEND parameters, you specify the same values that you specified on the PSTART and PEND parameters that defined the reference pattern for the area. If you used the STOKEN parameter on REFPAT
INSTALL, use it on REFPAT REMOVE.
The following REFPAT invocation removes the reference pattern that was defined
in Example 3 in “Examples of using REFPAT to define a reference pattern” on page
REFPAT REMOVE,PSTART=FIRSTB,PEND=LASTB
Chapter 19. Processor storage management
373
374
z/OS MVS Assembler Services Guide
Pobierz
Publiczny link zaktualizowany
Publiczny link do Twojego czatu został zaktualizowany. You may view and manage your chat links after registration here.
Publiczny link do dokumentu
Reklama
