Copy-on-write processing on z/TPF provides the capability for ECBs to work with unique copies of static data within a program. In addition, the z/TPF system uses copy-on-write processing to keep track of events that are unique to a specific program for each ECB. For instance, if a program has constructors that need to run only the first time a program is called, the system sets a flag in the program to indicate that the program was called and copy-on-write processing ensures that each ECB sees its own copy of that flag.
Copy-on-write processing is a valuable feature. But it can be costly, in terms of CPU utilization, when it is done hundreds of thousands of times per second. Testing done during development for PJ48146 showed a cost of approximately 225 million instructions per second (MIPS*) for each 50,000 copy-on-write operations per second that was performed.
There are three primary reasons for copy-on-write processing to occur on z/TPF:
- Static data updates by applications.
- z/TPF system code updates the first call flag for programs that require first call processing.
- z/TPF system code updates pointers to external data (data in one program referenced by another) when a new version of the program that contains the referenced data is loaded and activated.
With PJ48146, you can eliminate much of the copy-on-write processing due to reason 2, which is prevalent in C++ applications. Because the system still needs to keep track of whether constructors were called for a particular program by each ECB, this enhancement makes use of a storage area introduced by PJ45315 (overhead reduction for frequently entered programs). This ECB-unique storage area (FEP block) maintains information to let the system optimize enter/back linkage for programs that you define as frequently entered in the program configuration file. PJ48146 expands that information, reducing the maximum number of frequently entered programs that can be defined from 500 to 250, but adding the benefit of reduced copy-on-write processing.
Existing data collection reports show you how many times copy-on-write processing is being called and lists programs responsible for 90% of copy-on-write processing calls, but does not show you why copy-on-write processing is called. PJ48146 enhances the copy-on-write by program module report, which provides a separate count of copy-on-write calls made for first call processing. You might not see high FCCOW/sec rates if you do not have C++ applications handling message traffic.
In this example, programs highlighted in yellow incur a significant number of calls to copy-on-write processing due to first call processing. These can be avoided by defining the programs as frequently entered programs in the program configuration file. Generally, any program with a FCCOW/sec rate of 5,000 or higher is a good candidate to define as a frequently entered program. After defining the programs with non-zero FCCOW/sec values highlighted in yellow as frequently entered programs, the data collection report looks like the following example:
In this example, 109,000 copy-on-writes/second were eliminated and the overall copy-on-write/sec rate was reduced by nearly 50%. In our test scenario, this would equate to a savings of approximately 490 MIPS*.
Typically, programs with high FCCOW/sec rates are also frequently entered programs and were good candidates to define as frequently entered programs even before this enhancement. In that case, you will see a decrease in the C-O-W/sec rate compared to results from data collection taken before installation of this enhancement. However, you might see high FCCOW/sec rates for programs that do not show up in the cumulative program enters report. This can happen if a program that is called once per ECB (an application entry point) has constructors.
Review the copy-on-writes by program module report periodically. Programs that do not have constructors but have external data references can have a non-zero FCCOW/sec value only after a loadset has been activated that includes the program that contains the referenced data. Additionally, changes in applications can cause them to have constructors or to have references to external data. Often, these are compiler-generated and application developers might not be aware of them.
*Large System Performance Reference (LPSR) standard used for measuring MIPS. The actual cost that you will see on any particular z/TPF system is dependent on many factors.