TSO storage pools: cache performance as a function of average cache residency Figure 1.10.. The residency time objective of no less than 30 seconds, as just stated, provides an interest
Trang 1Hierarchical Reuse Model 21
Figure 1.9
time.
TSO storage pools: cache performance as a function of average cache residency
Figure 1.10
residency time
OS/390 system storage pools: cache performance as a function of average cache
Trang 2CICS: On-line Virtual Storage Access Method (VSAM) database storage under Customer Information and Control System (CICS) file control This variety of application accounted for the largest single contribution to the total storage seen in the survey
IMS: On-line Information Management System (IMS) database storage (more precisely, storage for databases accessed via the Data Language I (DL/I) database access language)
TSO: Storage for interactive users running under the Time Sharing Option (TSO)
System: Control files, program libraries, logs, and data used for system administration (Spool, scratch, and paging data were excluded from the system category)
This author’s reading of Figures 1.4 through 1.10 is that, if it is desired to ensure that “cache friendly” applications (at a minimum) receive substantial
benefits from the cache, an objective for T of at least 30–60 seconds can be
recommended If, in addition, it is desired to get substantial performance gains
from applications that are not “cache friendly”, a more demanding objective
may be needed
The residency time objective of no less than 30 seconds, as just stated, provides an interesting way to assess the cache memory sizes that have been offered since disk storage cache was first introduced This can be done by comparing them with the requirements given by (1.20) For this purpose, as
a rough distillation the data just presented, we shall use 0.25 and 0.7 as crude estimates of θ and b respectively
When the 3880 Model 13 cached storage control was first introduced in
1982, a typical storage subsystem provided up to 20 gigabytes of storage That storage control did not have the capability to accept write operations in cache; only read operations resulted in staging Thus, in applying (1.20) to its use of cache memory, only read operations should be counted in the rate of requests The typicalI/Orequirement against 20 gigabytes ofstorage capacity would have been roughly 120 I/O’s per second, of which, say, 90 I/O’s per second might have been reads At that time, the size of a typical track image was approximately .047 megabytes1 Thus, (1.20) calls for an amount of cache memory given by 0.047 x 0.7 x 90 x 300.75 = 38 megabytes This compares with a maximum cache size, in the 3880 Model 13, of 16 megabytes
As a result of the cache memory shortfall just outlined, the system adminis-trators responsible for many of the earliest storage controls found it necessary
to carefully manage the use of cache storage Cached storage controls were deployed selectively, for use with “cache friendly” data Also, extensive use was made of the facilities provided in these storage controls for limiting the
Trang 3Hierarchical Reuse Model 23
use of cache memory to identified volumes, while “turning off” access to the cache by other volumes
Cache sizes increased sharply with the introduction of the 3880 Model
23 storage control (maximum cache size 64 megabytes), and again with the
3990 Model 3 storage control (maximum cache size 256 megabytes) At the beginning of the 1990’s, a typical storage control was configured with approximately 120 gigabytes of storage capacity, and an I/O demand of, say,
300I/O’s per second Both reads and writes were cached By this time, memory management techniques had improved so that, when staging data as the result
of a miss, it was possible to allocate only enough memory for the requested record and subsequent records on the track (if a request then occurred for data before the requested record, a fairly unusual event, this would cause a so-called
“front-end miss”) Thus, the size of the most common track image at this time was 0.057 megabytes2, but we shall assume z = 0.04 megabytes (the
approximate memory allocation required, on average, for a stage) During this time, (1.20) would suggest that a typical storage control should have been configured with 0.04 x 0.7 x 300 x 300.75 = 108 megabytes of cache memory However, storage controls were often configured with less, since such memory was still fairly expensive Many installations adopted 64 megabytes as their standard cache size At this time, the use of explicit controls to restrict the use
of cache memory remained common
Today, storage controls offer far larger amounts of memory Most models
of storage control, for use in a OS/390environment, cannot be purchased with less than 1–2 gigabytes of cache A typical storage control might be configured with one terrabyte of storage capacity, and an I/Odemand of, say, 1000 I/O’s per second Such storage control configurations typically have more than enough cache, by the standards just discussed in the previous paragraph
Let us continue to assume that z = 0.04 megabytes (as before, this represents
the approximate average memory required to stage the contents of a standard track image, from the requested record to the end of the track) Then using the typical configuration just suggested, (1.20) calls for a cache size of 0.04 x 0.7 x
1000 x 300.75 = 359 megabytes This requirement is likely to be less than the configurable minimum size by a factor of several times Due to the fact that cache sizes today are so much more generous than those typical ten years ago, there now tends to be little or no use of strategies to explicitly control access to cache memory
In capacity planning for storage control cache, however, a more demanding objective must be adopted today than the minimal level of service obtained
using T = 30 seconds This is not only because more demanding objectives are easily achievable, but also because they are being achieved, day to day,
by running applications Very high standards of cache performance are both routine, and expected
Trang 4In moving an application from an older storage control to a newer one, the system administrator is well advised to keep an eye on the average cache residency time being delivered to applications, in order to avoid placing current service level agreements at risk This can be done using cache performance measurements which are standard in VM and OS/390 environments, together with the estimates of the average cache residency time presented previously in Subsection 4.2
While on the subject of residency time objectives, it is appropriate to include
a brief discussion of sequential workloads Sequential work plays an important
role in batch processing, particularly during off-shift hours The characteristics and requirements of sequential I/Ocontrast sharply with those of random-access
I/O, and in general sequential work must be analyzed as a special case, rather than using the same probabilistic or statistical methods that apply to a random-access environment
The next request for a given item of sequential data tends to be either
immediate, or a relatively long time in the future As a result, most cached
storage controls perform early demotion of sequential data residing in the cache;
the memory for such data is typically freed long before the data would have progressed from the top to the bottom of the LRUlist Storage controls also
typically use sequential prestage operations to bring data that appears to be due
for sequential processing into cache in advance of anticipated requests The net result of sequential prestage, coupled with early demotion, is that sequential processing tends to exhibit very high hit ratios and very light use of cache memory
When both sequential prestage and early demotion are being performed by the controller, tracks entering the cache via prestage are normally granted a much shorter cache visit time compared with tracks being staged due to a miss For this reason, it is impractical to specify a residency time objective for sequential work, nor is such an objective necessary to achieve good sequential performance
Due to the high hit ratios and light memory use characteristic of sequential processing, sequential workloads do not usually interfere with the practical analysis of cache memory requirements based upon Little’s law For example, (1.15) can still be applied to estimate the average residency time of the cache, even when sequential work is present For this purpose, only true misses, not sequential prestage operations, should be included in computing the miss ratio This limits the scope of Little’s law (the system “population”) to those tracks that age out of cache normally; hence, it yields an estimated average time for normal (rather than sequential) cache visits The small use of cache memory due to sequential tracks causes an upward error in the estimate, but
Trang 5Hierarchical Reuse Model 25
this error tends to be minor due to the light memory requirements for sequential processing
So far, despite our interest in a wide range of storage pools on both VM
andOS/390 systems, we have examined interarrival statistics on VM systems only This is due to the more complex nature of file buffering in OS/390 By contrast with the case for VM, any I/O trace collected in a production OS/390
environment is likely to reflect the presence of file buffers in the processor Therefore, before examining interarrival data obtained in this environment, it
is necessary to consider what impact should be expected from such buffers
It is not so much the performance of the processor buffers themselves which
complicate the picture developed so far, since their performance can be de-scribed by the methods of analysis already discussed Instead, it is necessary
to examine the impact that processor buffering has on the I/O requests being made to the storage subsystem
Typically, write requests issued by OS/390applications result in update
oper-ations in both the processor buffer area and the storage subsystem, since it is
necessary to ensure that the new information will be permanently retained (the
new data must be hardened), One copy of the data, however, is sufficient to
satisfy a read request For this reason, we must expect some read hits to occur only in the processor, which otherwise would have occurred in storage control cache
The effect of this on the cache miss ratio is easiest to see when the single-reference residency time in the processor is shorter than that in the cache, i.e., whenτc ≥ τp , where the subscripts c and p are used to denote processor and
storage control cache memories, respectively In this case, all the hits in the processor overlap with hits that would have occurred in the cache by itself, assuming that the cache’s single-reference residency time is held fixed The effect of processor buffering is, therefore, to reduce the number of requests to the cache without any reduction in cache misses For reads, we should therefore expect that
(1.25) where the prime indicates the miss ratio in the combined configuration
A more interesting configuration is one in which τc<τp In this environ-ment, a “division of labor” becomes possible, in which the processor buffer provides long residency times, while the storage control cache provides addi-tional hits by storing entire track images rather than individual records The analysis of this case is more complex, but it can be shown in this case also that the miss ratio for reads in the cache, with processor buffers also present, can
be estimated as a function of the miss ratios for the two memory technologies