Introduction

While it is impractical to give detailed performance formulae for either kernel or domain invocations, it is possible to offer information about various operations, and to offer average timings in some cases. Since Gnosis objects tend to be built of other objects, an optimization in a low-level object may have far-reaching implications in other objects.

It is impractical to give detailed performance formulae for the kernel because the performance of any operation may vary by orders of magnitude, depending whether, for example, the operands are readily accessible to the kernel, in kernel working storage, or on auxiliary (disk) storage. However, the following facts about the kernel implementation allow the application builder to avoid some programming practices that are much slower than alternatives. The following information is peculiar to the current kernel implementation, but we currently have few ideas how other kernel implementations might differ.

Gate Jump Times

This is the most highly optimized part of the kernel. When the kernel trace functions are not turned on, the minimal jump requires the execution of about 90 kernel instructions, about 5 of which are privileged. At least 120 instructions are required for the great majority of jumps. Few gate jumps require more than 200 instructions.

Primary Keys
Most primary keys require a few hundred kernel instructions to be executed.

Page and Node Faults
The kernel keeps recently accessed pages and nodes in core. An LRU algorithm is used to select these. About 5000 instructions are required to bring a page into core including those required to remove it from core.

Nodes are kept on disk in page size blocks called "node pots". When a node is required it is determined whether the containing node pot is already in core. If so a few hundred instructions move the node to where it can play its role as a node.

Sharing and Memory Mapping
General Points
Domains share segment tables when appropriate nodes in their memory trees are shared. Segment tables share page tables when 64K segments are defined by the same segment node. Pages tables share pages when the memory tree designates the same page.

Segment tables and page tables are reclaimed after long disuse.

As a direct consequence of the 370 architecture and the fact that we use 64K segments, the length of the segment table required by a domain is determined by the highest address used by a domain. The size in bytes of the required segment table is (largest virtual address)/2**14.

Changing segment nodes
Segment and page tables never allow more access than is called for by the memory trees of domains. When an action changes a node of a memory tree this must, in general, cause the modification of a segment or page table. Such changes are always invalidations of page or segment table entries. These entries remain invalid until a domain attempts to reuse the entry. At such times the entry is rebuilt according to the current memory tree. Two such associated events are likely to require together about 1000 kernel instructions.

The current implementation of the kernel fails to distinguish the modification of one slot of a segment node from the modification of the entire node. We may change this to limit the damage to the translation tables to that memory described by the altered slot.

Many domains hold a node key to the top node of their memory tree. It is convenient to use slots of this node as auxiliary key storage. Each such use severs the relationship of the domain from its segment table. The page tables will most probably remain intact. The segment table must be rebuilt again, one entry per fault.

Read only access
When a domain accesses a page via an address to which it has write access, that page will have storage key 1 (which is the PSW key of all user programs). When an address provides read-only access, that page will have storage key 0. Protection exceptions or translation exceptions must thus separate a sequence of accesses via read-only addresses from a sequence of accesses via read-write address. Such exceptions typically require several hundred kernel instructions depending on the complexity of the memory tree.

This effect can be severe if a domain accesses a page alternately via two addresses one of which provides read-only access and the other of which provides read-write access. It is more likely to strike when the page is shared by two domains with different authority to the page.

Styles of memory trees
Some styles of memory trees cause more overhead in the kernel than others. This is because we have made guesses of which will be more common and provided code to make them more efficient in several ways. In general it is good to have segment nodes hold memory keys where the lss of the key is one less than the lss of the node. Exceptions to this are termed "obscure" and cause extra overhead. Window keys are also obscure.

There are kernel tables with entries for each currently mapped obscurity. When these tables become full, old obscure segment and page table entries are sacrificed. There are counters to monitor such sacrifices and the size of these tables is variable by reassembling the kernel.

Meter Overhead
Some domains have a CPU cache associated with them. Such a cache lasts until:
it is exhausted,

the domain is long unused,

another domain which is under a common superior nearly empty meter requires the cached resource,

or some superior meter is examined or modified with a node key or used as other than a meter.

When this happens about 50 instructions per superior meter are required to reestablish the CPU cache.

Domain Overhead
Use of a domain key generally cause the domain to become unprepared whereas it must be prepared to run. Together, preparing and unpreparing a domain requires about 400 instructions. Reading or writing the registers of a domain prepare it instead of unprepairing it.

OS Simulation
CPU considerations during execution
The current implementation requires a total of 4-6 gate jumps to process most SVC and Program Interrupt activations. (2 gate jumps transfering control between .osprogram and .ossim, 2 gate jumps to store domain status, and up to 2 gate jumps to change registers and instruction counter, if necessary.) The CPU time used in processing the SVC or Program Interrupt is usually small compared to that required for gate jumps.

The pass through of interrupts destined for .debugger adds 1 gate jump, compared to the case where there was no .ossim domain.

The cost of creating an OSSIM environment
LOOSE END: Measure gate jumps and CPU time.

The creation of a .ossim domain keeper requires the creation of 2 supernodes (how much space each?) plus 4 nodes and 1 page for .ossim and 1 node for the meter of .osprogram.

Simultaneous Disk Access
If a file or a data base is implemented with a domain and the storage required for that object is mostly on disk there is a builtin limit to the rate of accessing that object. This limit stems from the fact the only disk operations are a result of faults and after a fault a domain waits until the page is in core.

Explain the ICM trick here!

Page Release
MVS supports a "Release Page" system call. The logical effect of this is to set some user specified storage to 0. The advantage of this is to conserve paging operations. This conservation occurs under two circumstances:
If the storage has not been referenced for a long while then it is unlikely to be in main store. If the data in those pages is not required the disk frames for those pages may be released. In this case the system need not bring the pages in but may merely provide zero page frames upon next reference to those addresses.

If the storage is unlikely to be required for a while and the values in the storage are no longer required, then a release page operation will immediately free real storage and also save the cost of writting the pages and the allocation of a disk frame.

The second advantage may already be had in Gnosis if the user will set pages to zero after he is done with the data there. Pages are tested for zero before they are written to the swap area. This does not, however, provide the advantage of early release of real page frames.

The first advantage may be had if we modify the kernel to notice that a page fault is caused by a MVCL that is destined to zero the page and marked the page as virtual zero and resumed the MVCL at the next page. The programmer would zero his large data areas just before using them and have the desired effect. This requires no changes to the external kernel specs.

Some applications require a large number of independent disk accesses per unit time. We enumerate here some limits that stem from the architecture of Gnosis and the current implementation of the kernel.

We will discuss the 3380 here to be definite although we now support only the 3330.

To achieve many disk accesses per second, many independent disk head access assemblies must be active at once.

To move a page requires the attention of an assembly for 25 ms and the attention of a channel (and controller) for about 2 ms.

If we assume 12 assemblies {6 3380's} per channel and 16 channels we come to an I/O performance figure of 8000 page reads per second. This is merely the hardware limitations. This gives us (2.4*10**11 = .94*2**38 = 3.75*16**9) bytes. This is the capacity of a large 3850 {mass store}.

Assume that we have a three domains per head assembly. Each of these domains will execute the code that accesses the faulted page. This is 576 domains.

What is the nature of the memory tree of these domains? We assume first that the data is collected into a single segment.

This depends on how we choose the domain.

We might allocate a domain to a subsection of the segment. The size of such a subsection would still be 2**29, much too large to map without windows or XA.

We might give the domain access to the entire segment and devote such a domain to a terminal session.

Our current kernel code places a limitation on itemspace size which means that the number of coreframes plus 19* the number of node frames < 2**16. We can thus reasonably expect about 2000 nodes in item space. Many more are quickly available in node pots.

See (projects,) for a list of kernel performance improvements (among other things).

We have made some performance observations of various functions on a 4341 Group II machine which has been called a one MIP machine. We report those observations in sections that reference this branch.

These observations were typically made by a PL/I program calling the routine BINTIME that returns the TOD value. These values are subtracted to measure elapsed times. To compensate for CPU interrupts the minimum time is normally reported. When times exceed 200 ms there is the likelihood that time slicing has taken its toll.