Managing the updating of storage keys

Abstract

The updating of components of storage keys is managed. A control program indicates whether the updating of selected components of a storage key can be bypassed. If the updating of the selected components can be bypassed, then depending on the circumstances, an update of the storage key may not need to be performed, saving on quiesce operations. The likelihood that the updating of a storage key can be bypassed is enhanced by selecting a block of storage, along with its associated storage key, from a designated queue or designated region of a queue.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent application Ser. No. 10/435,919, filed May 12, 2003, published Nov. 18, 2004, U.S. Publication No. U.S. 2004/0230749 A1, entitled “INVALIDATING STORAGE, CLEARING BUFFER ENTRIES, AND AN INSTRUCTION THEREFOR”, the entirety of which is hereby incorporated herein by reference.

Further, this application contains subject matter which is related to the subject matter of the following application, which is assigned to the same assignee as this application and is hereby incorporated herein by reference in its entirety:

“FILTERING PROCESSOR REQUESTS BASED ON IDENTIFIERS,” Siegel et al., (POU920030047US1), U.S. Ser. No. 10/436,361, filed May 12, 2003, published Nov. 18, 2004, U.S. Publication No. U.S. 2004/0230976 A1.

TECHNICAL FIELD

This invention relates, in general, to processing within a computing environment, and in particular, to managing the updating of storage keys employed during processing within the computing environment.

BACKGROUND OF THE INVENTION

Various existing computing environments, such as those based, for instance, on the z/Architecture, offered by International Business Machines Corporation, Armonk, N.Y., employ storage keys to facilitate processing within a computing environment. As one example, a storage key is associated with each block of real storage (also referred to as a frame). One function of a storage key is to provide a reliability mechanism that is used to segregate blocks of storage, ensuring that programs executing in one key do not improperly store into or, subject to a control in the key, fetch from blocks having a different key. A further function is to provide indications to an operating system as to which blocks have been referenced and changed, thus allowing the operating system to determine which blocks may need to be written to auxiliary storage.

A storage key is set, in one example, by a Set Storage Key Extended instruction, offered by International Business Machines Corporation, Armonk, N.Y. This instruction sets all of the constituent components of the key simultaneously, regardless of whether the various components are being set to the same value as before.

To improve system performance, a processor may buffer a subset of the storage keys in a local (processor-specific) area. However, when a storage key is changed, then all processors in a multi-processor configuration are to effectively observe the change simultaneously, such that stale local copies of the key are discarded. In one example, the Set Storage Key Extended instruction requires the system to be serialized to ensure that all CPUs observe the changes to the key. This serialization is performed in hardware using a fast quiesce mechanism, as an example.

When executing the Set Storage Key Extended operation with the fast quiesce mechanism, all processors within the same partition (or zone) as the requestor are quiesced. That is, each is to reach an interruptible point to honor the fast quiesce request. When honoring the request, the processors purge any local buffered copies of the key and all processors in that zone, besides the one that initiated the quiesce, resume execution but are prevented from accessing the relevant frame, while the operation is being performed. From an implementation perspective, the system quiesce is used to ensure that any local copy of the key is not out of date with respect to the system key and prevent inconsistent views of the key during the operation.

However, there is a large overhead associated with the hardware quiesce mechanism used to implement the Set Storage Key Extended instruction. For instance, only a limited number of quiesce operations (e.g., one in many environments) can be performed in the system at a time and the quiesce operations must be serialized in the storage controller hardware. This results in a large system impact for each quiesce, and therefore, for each update of the storage keys.

Based on the foregoing, a need exists for a capability that enables storage keys to be updated in a manner that minimizes the number of quiesces performed. In one example, a need exists for a storage key management capability that conditionally updates storage keys.

SUMMARY OF THE INVENTION

The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method of managing the updating of storage keys of a computing environment. The method includes, for instance, indicating by a control program whether one or more selected components of a storage key are to be updated; comparing one or more components of the storage key to one or more values, wherein inclusion of the one or more selected components in the comparing depends on the indicating; and updating zero or more components of the storage key based on the comparing.

System and computer program products corresponding to the above-summarized method are also described and claimed herein.

In a further aspect of the present invention, a queue stored in memory of a computing environment and accessed by a program of the computing environment to obtain a block of storage is provided. The queue includes, for instance, one region of the queue being designated to exclusively include one or more blocks of storage with associated storage keys, in which each storage key of the associated storage keys includes one or more storage key components having respective specified values; and another region of the queue being designated to include one or more blocks of storage with associated storage keys that are excluded from the one region.

In yet a further aspect of the present invention, a queue stored in memory of a computing environment and accessed by a program of the computing environment to obtain a block of storage is provided. The queue includes, for instance, one or more blocks of storage and associated storage keys, wherein each storage key of the associated storage keys has one or more storage key components of respective specified values, wherein a block of storage having a storage key in which at least one storage key component of the one or more storage key components has a different value from the respective specified value is excluded from the queue.

In yet another aspect of the present invention, an instruction to be executed within a computing environment is provided. The instruction includes, for instance, an operation code to identify an instruction to be executed; a control field used by a control program to indicate whether updating of one or more selected components of a storage key can be bypassed; a first field providing an indication of one or more values to be compared to one or more values of one or more components of the storage key; and a second field providing an indication of the storage key to be set.

In yet a further aspect of the present invention, a computing environment is provided that includes a memory to store an instruction to conditionally set a storage key of the computing environment, the instruction having a control field provided by a control program to indicate whether updating of one or more selected components of the storage key can be bypassed; an instruction fetch unit to fetch the instruction from memory; an instruction decode unit to decode the instruction of the instruction fetch unit; and an instruction execution unit to execute the decoded instruction.

Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more aspects of the present invention are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

FIG. 1 depicts one embodiment of a computing environment to incorporate and use one or more aspects of the present invention;

FIG. 2 depicts one embodiment of further details associated with a controller of FIG. 1, in accordance with an aspect of the present invention;

FIG. 3 depicts one embodiment of a host computer that can emulate another computer, in accordance with an aspect of the present invention;

FIG. 4 depicts one example of the various components of a storage key, in accordance with an aspect of the present invention;

FIG. 5 depicts one embodiment of an overview of the logic for conditionally updating components of a storage key, in accordance with an aspect of the present invention;

FIG. 6a depicts one embodiment of a format of a conditional Set Storage Key Extended (SSKE) instruction, in accordance with an aspect of the present invention;

FIG. 6b depicts one embodiment of the fields associated with the M3 operand of the conditional SSKE instruction of FIG. 6a, in accordance with an aspect of the present invention;

FIGS. 7a-7b depict one embodiment of the logic associated with the conditional SSKE instruction, in accordance with an aspect of the present invention;

FIG. 8a depicts one embodiment of a queue of available frames configured in accordance with an aspect of the present invention; and

FIG. 8b depicts another embodiment of a queue of available frames configured in accordance with an aspect of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

In accordance with an aspect of the present invention, a storage key management capability is provided that conditionally updates selected components of a storage key, thereby minimizing quiesce operations and enhancing system performance. In a further aspect of the present invention, the storage key management capability includes placing available frames with storage keys in available frame queues that are organized in such a manner that a selected available frame has a higher probability of having a desired storage key, thus minimizing the need to update the key.

One embodiment of a computing environment 100 to incorporate and use one or more aspects of the present invention is described with reference to FIG. 1. Computing environment 100 is based, for instance, on the z/Architecture offered by International Business Machines Corporation, Armonk, N.Y. The z/Architecture is described in an IBM® publication entitled, “z/Architecture Principles of Operation,” IBM Publication No. SA22-7832-03, June 2004, which is hereby incorporated herein by reference in its entirety. (IBM® is a registered trademark of International Business Machines Corporation, Armonk, N.Y., U.S.A. Other names used herein may be registered trademarks, trademarks or product names of International Business Machines Corporation or other companies.) In one example, a computing environment based on the z/Architecture includes an eServer zSeries, offered by International Business Machines Corporation, Armonk, N.Y.

As one example, computing environment 100 includes a central processor complex (CPC) 102 coupled to a controller 120. Central processor complex 102 includes, for instance, one or more partitions or zones 104 (e.g., logical partitions LP1-LPn), one or more central processors 106 (e.g., CP1-CPm), and a hypervisor 108 (e.g., a logical partition manager), each of which is described below.

Each logical partition 104 is capable of functioning as a separate system. That is, each logical partition can be independently reset, initially loaded with an operating system, if desired, and operate with different programs. An operating system or application program running in a logical partition appears to have access to a full and complete system, but in reality, only a portion of it is available. A combination of hardware and Licensed Internal Code (also referred to as microcode or millicode) keeps a program in a logical partition from interfering with a program in a different logical partition. This allows several different logical partitions to operate on a single or multiple physical processors in a time sliced manner. In this particular example, each logical partition has a resident operating system 110, which may differ for one or more logical partitions. In one embodiment, operating system 110 is the Z/OS operating system, offered by International Business Machines Corporation, Armonk, N.Y.

Central processors 106 are physical processor resources that are allocated to the logical partitions. For instance, a logical partition 104 includes one or more logical processors, each of which represents all or a share of a physical processor resource 106 allocated to the partition. The logical processors of a particular partition 104 may be either dedicated to the partition, so that the underlying processor resource is reserved for that partition; or shared with another partition, so that the underlying processor resource is potentially available to another partition.

Logical partitions 104 are managed by hypervisor 108 implemented by microcode running on processors 106. Logical partitions 104 and hypervisor 108 each comprise one or more programs residing in respective portions of central storage associated with the central processors. One example of hypervisor 108 is the Processor Resource/Systems Manager (PR/SM), offered by International Business Machines Corporation, Armonk, N.Y.

Controller 120, which is coupled to the central processor complex, includes centralized logic responsible for arbitrating between different processors issuing requests. For instance, when controller 120 receives a request, it determines that the requester is the master processor for that request and that the other processors are slave processors; it broadcasts messages; and otherwise, handles requests. One example of a controller is described in U.S. Pat. No. 6,199,219, entitled “System Serialization With Early Release Of Individual Processor,” Webb et al., Sep. 12, 2000, which is hereby incorporated herein by reference in its entirety. Further details are also described with reference to FIG. 2.

FIG. 2 depicts one example of a controller 200 coupled to a plurality of central processors (CPUs) 201. In this example, two central processors are depicted. However, it will be understood that more than two processors may be coupled to controller 200.

Controller 200 includes various controls including, for instance, system serialization controls 202. The system serialization controls are used to ensure that operations that are to be serialized, such as update operations, are serialized, in that only one such operation (or a limited number) is in progress at one time in the computing environment. It also monitors the sequence of events for that operation.

Controller 200 is coupled to each central processor via various interfaces. For instance, an interface 204 is used by the Licensed Internal Code in a central processor to send “control” commands to the controller, which specify an action to be taken, and to send “sense” commands, which return information from the controller. Another interface is a response bus 206, which is used to return information from the controller for the “sense” commands. The response bus is also used to communicate command status for “control” commands, and may be set from a plurality of sources within the controller, including the system serialization controls. A central processor can use this interface to sense the state of the system serialization controls in controller 200.

A further interface is interface 208, which is used by the controller to send commands to each CPU. This may also be controlled from a plurality of sources within the controller, including system serialization controls 202. A yet further interface is interface 210, which provides signals to cache controls 212 of central processor 201. Cache controls 212 process commands, in response to the signals. In one example, cache controls 212 process commands that affect one or more buffers, such as Translation Lookaside Buffers (TLBs) 213.

In addition to cache controls 212, central processor 201 includes various other controls, including for instance, interrupt controls 220 and execution controls 222. In response to particular events, interrupt controls 220 cause an internal interruption to be pending in the CPU, which in turn, causes execution controls 222 to suspend program instruction processing, at the next interruptible point. In response to the interruption, execution controls 222 invokes a Licensed Internal Code routine to set a broadcast operation allowed latch 224 to enable cache controls 212 to process pending commands.

Central processor 201 also includes a CPU quiesced latch 226 that indicates whether or not the central processor is quiesced.

The above-described computing environment is only one example. Many variations are possible without departing from the spirit of the present invention. For example, one or more partitions can be running in different architecture modes. Further, as other examples, the environment need not be partitioned and/or the environment need not be based on the z/Architecture, but instead, can be based on other architectures offered by Intel, Sun Microsystems, as well as others. Moreover, an environment may include an emulator (e.g., software or other emulation mechanisms) in which a particular architecture or a subset thereof is emulated. In such an environment, one or more emulation functions of the emulator can implement one or more aspects of the present invention, even though a computer executing the emulator may have a different architecture than the capabilities being emulated. As one example, in emulation mode, the specific instruction or operation being emulated is decoded, and an appropriate emulation function is built to implement the individual instruction or operation.

Further details of an emulation environment are described with reference to FIG. 3. As one example, a host computer 300 is capable of emulating another architecture, computer and/or processing capabilities of another computer. For instance, host computer 300 is based on an Intel architecture; a RISC architecture, such as PowerPC; a SPARC architecture, offered by Sun Microsystems; or another architecture, and is capable of emulating the z/Architecture of IBM® or another architecture of IBM® or another entity.

Host computer 300 includes, for instance, a memory 302 to store instructions and data; an instruction fetch unit 304 to fetch instructions from memory 302, and to optionally, provide local buffering for the fetched instructions; an instruction decode unit 306 to receive instructions from instruction fetch unit 304 and to determine the type of instructions that have been fetched; and an instruction execution unit 308 to execute the instructions. Execution may include loading data into a register from memory 302; storing data back to memory from a register; or performing some type of arithmetic or logical operation, as determined by the decode unit.

In one example, each unit described above is implemented in software. For instance, the operations being performed by the units are implemented as one or more subroutines within emulator software. In another example, one or more of the operations are implemented in firmware, hardware, software or some combination thereof.

Further, although FIG. 3 is described with reference to emulation, the environment of FIG. 3 need not be an emulation environment. In another example, instructions are executed in a native environment, and the operations are implemented in hardware, firmware, software or some combination thereof.

In computing environments based on the z/Architecture, as an example, each block (e.g., 4 k bytes) of storage (e.g., real storage) has associated therewith a storage key. As described above, a storage key provides a reliability mechanism that is used to segregate blocks of storage, ensuring that programs executing in one key do not accidentally store into blocks having a different key. Further, a storage key provides indications to an operating system as to which blocks have been referenced and changed, thus allowing the operating system to determine which blocks may need to be written to auxiliary storage.

One example of a storage key is described with reference to FIG. 4. A storage key 400 includes for instance, an access control (ACC) component 402, a fetch protection (F) component 404, a reference (R) component 406, and a change (C) component 408, each of which is described below.

Access control bits (ACC) 402: If a reference is subject to key-controlled protection, the access control bits are matched with an access key (e.g., of the program status word or from an instruction operand) when information is stored, or when information is fetched from a location that is protected against fetching.

Fetch-protection bit (F) 404: If a reference is subject to key-controlled protection, the fetch protection bit controls whether key-controlled protection applies to fetch-type references; a 0 indicates that only store-type references are monitored and that fetching with any access key is permitted; a 1 indicates that key-control protection applies to both fetching and storing. No distinction is made between the fetching of instructions and of operands.

Reference bit (R) 406: The reference bit normally is set to 1 each time a location in the corresponding storage block is referred to either for storing or for fetching of information.

Change bit (C) 408: The change bit is set to 1 each time information is stored at a location in the corresponding storage block.

Storage keys are not part of addressable storage. In one example, to set a storage key, a Set Storage Key Extended instruction is used. One embodiment of this instruction is described in an IBM® publication entitled, “z/Architecture Principles of Operation,” IBM Publication No. SA22-7832-03, June 2004, which is hereby incorporated herein by reference in its entirety. This instruction sets all components of the storage key, even if one or more of the components are being updated to the same value as before. Moreover, as described above, this instruction requires the system to be serialized to ensure that all CPUs observe the changes to the key.

This unconditional updating and serialization associated with updating storage keys, and in particular, associated with the Set Storage Key Extended instruction, have negative impacts on system performance and overhead. Thus, in accordance with an aspect of the present invention, a capability is provided that enables conditional updating of storage keys, and thus, conditional system serialization. As one example, the operating system or other control program (both of which are referred to herein as the program) of the computing environment manages the conditional updating by indicating which components of a storage key may be bypassed for updating. The program has control over the updates and it allows conditional bypassing of updates, as described in further detail below.

One embodiment of an overview of the conditional updating aspect of the present invention is described with reference to FIG. 5. Initially, the operating system or other control program indicates whether one or more selected components of a storage key are to be (i.e., are required to be) updated, STEP 500. For instance, the operating system may indicate that the change control and/or reference control need not be updated.

Thereafter, comparisons are performed on one or more components of the storage key, STEP 502. Inclusion of the one or more selected components in the comparing depends on the operating system indication. For instance, if the indicating specifies that the reference control and/or change control need not be updated, then the comparing is allowed to ignore those controls. If the comparison of a component indicates that an update is to be performed, INQUIRY 504, then an update of one or more components of the storage key is performed, STEP 506. In one embodiment, only the components that need updating are updated. In other embodiments, however, all of the components are updated, even those components that do not need updating, if an updating is to be performed. During the updating, serialization may be performed as described below. However, not all updating requires serialization.

Returning to INQUIRY 504, if the comparison indicates that an update is not needed, then it is not necessary to perform the update and any required serialization.

In one example, the conditional updating is performed via a conditional Set Storage Key Extended instruction. This instruction allows the program to conditionally bypass the updating of, for instance, the reference component, the change component or both, when circumstances allow. That is, software (e.g., the program) can indicate that either or both of these components do not need to be updated. This allows the CPU flexibility in implementation when the access key and fetch protection controls being set by the Set Storage Key Extended instruction match those currently in the key to be updated. Depending on the action requested with respect to the reference and change controls, the CPU can often avoid quiescing the system as part of the storage key update, as described in further detail below.

One embodiment of a format of a conditional Set Storage Key Extended (SSKE) instruction is described with reference to FIG. 6a. A conditional SSKE instruction 600 includes, for instance, an operation code 602 designating the Set Storage Key Extended instruction; an M3 operand 604 used by the program to indicate which components of the storage key need not be updated; a register designation 606 selecting a register that includes values to be compared to components of the storage key; and a register designation 608 selecting a register that includes the address of the storage key to be conditionally set.

Further details regarding the M3 operand are described with reference to FIG. 6b. In one example, M3 operand 604 includes a reference bit update mask (MR) 610 and a change bit update mask (MC) 612. MR 610 controls whether updates to the reference component of the storage key may be bypassed, and MC 612 controls whether updates to the change component of the storage key may be bypassed. Use of these controls is described further with reference to the logic flow of FIGS. 7a-7b.

In particular, one embodiment of the logic associated with executing a conditional Set Storage Key Extended instruction is described with reference to FIGS. 7a-7b. As one example, this instruction is invoked by the operating system (or a component thereof) and executed in millicode of a processor of the computing environment.

Initially, a determination is made as to whether the conditional Set Storage Key Extended facility is installed, INQUIRY 700 (FIG. 7a). This determination is made, by, for instance, checking an indicator that specifies whether the facility is installed. If the facility is not installed, then processing occurs as before and the entire key is set regardless of the changes to the components, STEP 702 (FIG. 7b). That is, when the conditional Set Storage Key Extended facility is not installed, the M3 operand is ignored, and the storage key for the block that is addressed by the contents of general register R2 is replaced by values (e.g., bits) from general register R1, STEP 702, and the instruction completes without changing the condition code, STEP 704.

However, if the conditional Set Storage Key Extended facility is installed, INQUIRY 700, then a further determination is made as to whether the reference bit update mask (MR) and the change bit update mask (MC) are zero, INQUIRY 706. If both the MR and MC controls are zero, then, the instruction completes as though the conditional Set Storage Key Extended facility is not installed. Again, the storage key for the block that is addressed by the contents of general register R2 is replaced by bits from general register R1, STEP 702, and the instruction completes without changing the condition code, STEP 704. When the conditional-SSKE facility is not installed, the M3 field of the instruction (including the MR and MC bits) is not defined, thus these bits of the instruction should contain zeros. By completing as though the conditional-SSKE facility was not installed when both the MR and MC controls are zero, backward compatibility is provided to programs that do not support the facility.

When either or both the reference bit update mask and change bit update mask controls are one, then a copy of the storage key (or a portion thereof) for the block addressed by general register R2 is saved in a temporary copy (referred to herein as OKey), STEP 708. If an unrecoverable error, such as an invalid checking block code, is detected when fetching the storage key, INQUIRY 710, then a condition code indicating such is set, STEP 711 and the entire storage key for the block is replaced by specified bits (e.g., bits 56-62) of general register R1, STEP 702, and the contents of specified bits (e.g., bits 48-55) of general register R1 are unpredictable.

Returning to INQUIRY 710, if an uncorrectable error has not occurred when accessing the storage key, then prior to any modification, the contents of the original storage key for the block that is addressed by general register R2 are placed in specified bit positions (e.g., bits 48-54) of general register R1 and a specified bit (e.g., bit 55) of general register R1 is set to zero, STEP 712. Other bits (e.g., bits 0-47 and 56-63) of the register remain unchanged.

Thereafter, the access control bits and fetch protection bit of the storage key for the designated block are compared with the corresponding fields in specified bits (bits 56-60) of general register R1, STEP 714. If the respective fields are not equal, a condition code indicating such is set, STEP 716, and the entire storage key for the block is replaced by bits (e.g., bits 56-63) from general register R1, STEP 702.

However, when the access control and fetch protection bits in the storage key are equal to the respective bits in general register R1, processing continues with a determination as to which of the MR and MC controls are equal to 1, STEP 718. When both the MR and MC controls are 1, indicating updating of the reference and change components can be bypassed, the instruction completes by setting an appropriate condition code, STEP 720, and the storage key remains unchanged. Therefore, in this case, no quiesce is performed because no updates are needed.

If, however, one of the MR and MC controls is not equal to 1, then a further determination is made as to whether it is the MR control that is equal to 0, INQUIRY 722. If the MR control is 0 and the MC control is 1, then the reference bit of the storage key for the designated block is compared with a specified bit (e.g., bit 61) of general register R1, STEP 724. If the bits are equal, the instruction completes by setting an appropriate condition code, STEP 720, and the storage key remains unchanged. Again, no quiesce is performed, since no update is necessary.

Returning to INQUIRY 724, if the bits are not equal, then a determination is made as to whether the entire storage key for the designated block is to be replaced by the bits in general register R1, INQUIRY 726. This determination is made based on the implementation for the particular model. For example, on some machines, a desired reference or change bit can be set directly without a quiesce, in a manner which may influence the other of these bits (making its value unpredictable), whereas clearing the desired bit requires a quiesce. Thus, setting the bit alone results in a partial setting of the key, whereas the clearing operation is more simply implemented with the existing logic to quiesce and change the entire key. Accordingly, if this model-dependent logic determines that the entire storage key is to be updated, then processing continues with STEP 716. Otherwise, the reference bit for the storage key is replaced by a specified bit (e.g., bit 61) of general register R1 and the change bit for the key is unpredictable, STEP 728. The instruction completes by setting an appropriate condition code, STEP 730.

Returning to INQUIRY 722, when the MC control is zero and the MR control is one, the change bit of the storage key for the designated block is compared with a specified bit (e.g., bit 62) of general register R1, INQUIRY 732. If the bits are equal, the instruction completes by setting an appropriate condition code, STEP 720, and the storage key remains unchanged.

However, if the bits are not equal, INQUIRY 732, a determination is made as to whether the entire key is to be updated, INQUIRY 734, using model-dependent logic like that in INQUIRY 726 above. If the entire key is to be updated, then the storage key for the designated block is replaced by the bits in general register R1, STEP 702, and the instruction completes by setting an appropriate condition code, STEP 716. However, if the entire key is not to be updated, then the change bit for the storage key is replaced by a specified bit (e.g., bit 62) of general register R1 and the reference bit for the key is unpredictable, STEP 736. The instruction completes by setting an appropriate condition code, STEP 730.

In the 24-bit addressing mode, bits 40-51 of general register R2 designate a block in real storage, and bits 0-39 and 52-63 of the register are ignored. In the 31-bit addressing mode, bits 33-51 of general register R2 designate a block in real storage and bits 0-32 and 52-63 of the register are ignored. In the 64-bit addressing mode, bits 0-51 of general register R2 designate a block in real storage, and bits 52-63 of the register are ignored.

The new 7-bit storage key value, or selected bits thereof, is obtained from bit positions 56-62 of general register R1. The contents of bit positions 0-55 and 63 of the register are ignored. When the conditional Set Storage Key Extended facility is installed, and either or both the MR and MC bits are 1, bit position 63 should contain a zero.

Described in detail above is a capability for managing the updating of storage keys. This capability is used by, for instance, a control program, in situations in which the control program is to set a storage key for a block of real storage. The control program is coded to indicate whether the updating of one or more of the components of the storage key may be bypassed.

As one particular example, z/OS Real Storage Manager (RSM) modules are capable of using one or more capabilities of the present invention, including the enhanced controls in SSKE. For example, in a first-reference fault scenario where both the reference and change bits are not important (since if they are not already on, they are turned on by the hardware when something is written into the page), using the conditional SSKE instruction of an aspect of the present invention avoids a quiesce operation, if the ACC and F bits of the key match the desired (or specified) value. When a page is brought in from auxiliary storage and if the auxiliary copy is being freed, the operating system cares about setting the ACC, F and change bits of the key, but not the reference bit (since again if not already on, it will be turned on shortly when the page is referenced). Many other components of an operating system or a computing environment can use one or more capabilities of the present invention, including, but not limited to, the conditional Set Storage Key Extended operation.

To increase performance associated with the conditional Set Storage Key Extended instruction, it is desirous to select blocks of storage (e.g., frames), when needed, that already have the desired storage key. By making such a selection, when the Set Storage Key Extended instruction is invoked, the key does not need to be updated, thus potentially saving a quiesce operation. Therefore, in a further aspect of the present invention, an available frame with its associated key is strategically placed in a queue of available frames 800 (see FIG. 8a) for selection when needed. The frame is placed in the queue based on the previous values of one or more components of the key (e.g., previous values of the ACC and F components). For instance, frames having a storage key with the selected combination of ACC=8 and F=1 (referred to herein as a selected set) are placed at one end 802 of the available frame queue, while frames having storage keys with combinations other than ACC=8 and F=1 are placed at one or more other locations 804 of the queue and not in any particular order.

In particular, as shown in FIG. 8a, queue 800 includes, as one example, a frame queue segment 805 at one end 802 of the queue. This segment includes or points to one or more frames 806 with associated storage keys 808. Each storage key of this segment has one or more components (in this example, two components) with respective specified values (e.g., a value of 8 for the ACC component and a value of 1 for the F component).

Frames with storage keys in which those components have values other than the respective specified values are not included in this segment. For example, storage keys in which ACC=8 and F=0, or ACC=any value other than 8 and F=0 or 1 are not included in this segment, but instead, are placed at another end of the queue. In this particular example, only storage keys with ACC=8 and F=1 are included in segment 805.

The selected set of requested keys can be placed at either end of the queue or at another designated region within the queue. By setting up the queue in this manner, when a new frame is requested, the frame is chosen from the queue (or segment of the queue) corresponding to the ACC and F to be assigned, assuming one is available. This increases the chances that a quiesce can be avoided. However, in this implementation, no checking is performed to determine if there are frames in the desired queue segment; they are either there or not. If not there, then a quiesce might have to be performed when setting the storage key to the desired value.

In another embodiment, a queue includes a plurality of selected sets of frames. For instance, as depicted in FIG. 8b, a queue 810 includes a plurality of different regions 812a-812n and a particular region can be designated for frames that have storage keys in which selected components have respective specified values. For instance, region 812a is designated for frames having storage keys with ACC=0, F=1; region 812c is designated for frames having storage keys with ACC=1, F=1, etc. Although various regions are shown in this one example, a queue may have any number of desired regions.

To obtain a frame from a queue organized in this manner, the appropriate frame queue segment header is chosen by indexing into the queue based on the key and fetch protect attributes and selecting a frame therefrom, if that segment is not empty. If that segment is empty, then a frame is selected from another segment. The another segment is chosen, as one example, in order from the least popular key to the most popular key.

There may be one or more available frame queues organized, as described above, and one or more of those queues may be segmented to include frames with key components of certain values. Further, there may be one queue for each key type. For instance, one queue is organized in such a manner that it only includes storage keys in which ACC and F equal respective specified values. Many other variations exist and are considered a part of the claimed invention.

Although in the above embodiments, storage keys having a combination of ACC=x and F=y are described, the segmentation may be based, in other embodiments, on the value of just one selected component or on the values of more than two selected components or on the values of selected components other than ACC and/or F. Many variations exist and are considered a part of the claimed invention.

Described in detail above is a capability for managing the updating of storage keys, while minimizing quiesce operations. Advantageously, with one or more aspects of the present invention, the number of quiesce operations and associated overhead are reduced; performance within a single image or partition is improved; and overall system overhead is reduced, since there is less of a load on the quiesce engine.

In one embodiment, an SSKE instruction format is provided that allows for masking of reference and change bit updates. In particular, software is able to mask the update of the reference and/or change bit, when possible. Further, the CPU has flexibility in implementation when the access key and fetch-protection components being set by SSKE match those currently in the key. Depending on the action requested with respect to the reference and change controls, the CPU can often avoid quiescing the system as part of the storage key update.

The various embodiments described above are just examples. There may be many variations to these embodiments without departing from the spirit of the present invention. For instance, although a logically partitioned environment is described herein, this is only one example. Aspects of the invention are beneficial to many types of environments, including other environments that have a plurality of zones, and non-partitioned environments. Further, there may be no central processor complexes, but yet, multiple processors coupled together. Yet further, one or more aspects of the invention are applicable to single processor environments.

Moreover, although a specific instruction is described herein, many variations can be made without departing from the spirit of the present invention. For example, different opcodes, different fields, different registers or even no registers, different bits, etc. may be used. As one particular example, other instruction set architectures may define an equivalent instruction in somewhat different ways (e.g., different opcodes, different fields in the instruction, different registers used, etc.), but one or more aspects of the present invention still apply. Many other variations are also considered a part of the claimed invention. For instance, although certain bits are specified herein, different bits may be used without departing from the spirit of the present invention. Further, sizes other than bits may be used. Again, many other variations can be made without departing from the spirit of the present invention.

As used herein, the term “processing unit” includes processors, execution units, emulators and/or other similar components, and the terms “storage” and “memory” are used interchangeably. Further, although a block of storage is defined as 4 k herein, in other embodiments, it can be a size other than 4 k. Moreover, the phrase “a field providing an indication of”, as used herein, includes, as examples, the field itself having the particular values or information, and/or the field including an indication of where the values or information can be found (e.g., a register, storage area, etc.).

The capabilities of one or more aspects of the present invention can be implemented in software, firmware, hardware or some combination thereof.

One or more aspects of the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has therein, for instance, computer readable program code means or logic (e.g., instructions, code, commands, etc.) to provide and facilitate the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.

Additionally, at least one program storage device readable by a machine embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.

The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.

Although preferred embodiments have been depicted and described in detail herein, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions and the like can be made without departing from the spirit of the invention and these are therefore considered to be within the scope of the invention as defined in the following claims.

Claims

1. A method of managing updating of storage keys of a computing environment, said method comprising:

indicating by a control program whether one or more selected components of a storage key are to be updated;

comparing one or more components of the storage key to one or more values, wherein inclusion of the one or more selected components in the comparing depends on the indicating; and

updating zero or more components of the storage key based on the comparing.

2. The method of claim 1, wherein a storage key comprises a key associated with a block of storage of the computing environment, said key being employed in at least one of segregating blocks of storage and indicating to an operating system of the computing environment whether the block has been at least one of referenced and changed.

3. The method of claim 1, wherein the one or more selected components comprise fewer components than all of the components of the storage key.

4. The method of claim 1, wherein the indicating comprises providing one or more masks for the one or more selected components to indicate whether the one or more selected components are to be updated.

5. The method of claim 4, wherein the one or more selected components comprise a change control that specifies whether a storage block associated with the storage key has been changed and a reference control that specifies whether the storage block has been referenced.

6. The method of claim 1, wherein the storage key is associated with a block of storage of the computing environment, and wherein the comparing comprises comparing one or more values of the one or more components to one or more values of a storage key previously associated with the block of storage.

7. The method of claim 1, wherein the updating comprises updating one or more components of the storage key, but fewer than all of the components of the storage key.

8. The method of claim 1, wherein the storage key is associated with a block of storage of the computing environment, and wherein:

the indicating indicates whether updating of at least one of a reference control and a change control can be bypassed;

the comparing compares values of an access control and a fetch control to values of an access control and a fetch control of a storage key previously associated with the block of storage, the comparing refraining from performing a comparison on the reference control, should the indicating specify updating of the reference control can be bypassed and the comparing refraining from performing a comparison on the change control, should the indicating specify updating of the change control can be bypassed; and

the updating updates at least the access control, should the comparing of the access controls indicate a difference, and the updating updates at least the fetch control, should the comparing of the fetch controls indicate a difference.

9. The method of claim 1, wherein at least one of the indicating, comparing and updating is performed via an instruction executing in the computing environment.

10. The method of claim 9, wherein the instruction is implemented in at least one of hardware, firmware and software.

11. The method of claim 9, wherein the instruction is executed by a processing unit emulating an architecture of the instruction.

12. The method of claim 1, wherein the storage key is associated with a block of storage, and wherein the method further comprises selecting the block of storage from a queue, wherein the selecting comprises selecting the block of storage from one of: a queue designated to exclusively include blocks of storage with storage keys having one or more storage key components with respective specified values, and a queue having a plurality of regions in which each region of one or more regions of the plurality of regions of the queue is designated to include blocks of storage with storage keys having one or more one storage key components with respective specified values.

13. A queue stored in memory of a computing environment and accessed by a program of the computing environment to obtain a block of storage, said queue comprising:

one region of the queue, said one region being designated to exclusively include one or more blocks of storage with associated storage keys, in which each storage key of the associated storage keys includes one or more storage key components having respective specified values; and

another region of the queue, said another region being designated to include one or more blocks of storage with associated storage keys that are excluded from the one region.

14. The queue of claim 13, wherein the one region is at one end of the queue.

15. The queue of claim 13, wherein the one region is at one location within the queue and the another region is at another location within the queue.

16. The queue of claim 13, further comprising one or more additional regions, wherein an additional region of the one or more additional regions is designated for one or more blocks of storage with associated storage keys, in which each storage key of the associated storage keys of this additional region includes one or more storage key components having respective selected values, wherein at least one respective selected value of at least one storage key component differs from at least one respective specified value of the corresponding at least one storage key component.

17. An instruction to be executed within a computing environment, said instruction comprising:

an operation code to identify an instruction to be executed;

a control field used by a control program to indicate whether updating of one or more selected components of a storage key can be bypassed;

a first field providing an indication of one or more values to be compared to one or more values of one or more components of the storage key; and

a second field providing an indication of the storage key to be set.

18. The instruction of claim 17, wherein the operation code comprises a code specifying a set storage key extended instruction.

19. The instruction of claim 17, wherein the computing environment comprises a processing unit to execute the instruction, the processing unit emulating an architecture of the instruction.

20. The instruction of claim 17, wherein the control field comprises at least one mask used in the indication.

21. A computing environment comprising:

a memory to store an instruction to conditionally set a storage key of the computing environment, the instruction having a control field provided by a control program to indicate whether updating of one or more selected components of the storage key can be bypassed;

an instruction fetch unit to fetch the instruction from memory;

an instruction decode unit to decode the instruction of the instruction fetch unit; and

an instruction execution unit to execute the decoded instruction.

22. The computing environment of claim 21, wherein one or more of the instruction fetch unit, the instruction decode unit and the instruction execution unit are implemented as one or more routines of an emulator.

23. A system of managing updating of storage keys of a computing environment, said system comprising:

a control program to indicate whether one or more selected components of a storage key are to be updated; and

a processing unit to compare one or more components of the storage key to one or more values, wherein inclusion of the one or more selected components in the comparing depends on the indication, and to update zero or more components of the storage key based on the comparison.

24. The system of claim 23, wherein the control program provides one or more masks for the one or more selected components to indicate whether the one or more selected components are to be updated.

25. The system of claim 23, wherein the storage key is associated with a block of storage of the computing environment, and wherein the compare comprises comparing one or more values of the one or more components to one or more values of a storage key previously associated with the block of storage.

26. The system of claim 23, wherein the storage key is associated with a block of storage of the computing environment, and wherein:

the control program indicates whether updating of at least one of a reference control and a change control can be bypassed;

the compare compares values of an access control and a fetch control to values of an access control and a fetch control of a storage key previously associated with the block of storage, the compare refraining from performing a comparison on the reference control, should the indication specify updating of the reference control can be bypassed and the compare refraining from performing a comparison on the change control, should the indication specify updating of the change control can be bypassed; and

the update updates at least the access control, should the comparison of the access controls indicate a difference, and the updating updates at least the fetch control, should the comparison of the fetch controls indicate a difference.

27. An article of manufacture comprising:

at least one computer usable medium having computer readable program code logic to manage updating of storage keys of a computing environment, the computer readable program code logic comprising: compare logic to compare one or more components of a storage key to one or more values, wherein inclusion of one or more selected components of the storage key in the comparing depends on whether a control program has indicated that the one or more selected components of the storage key are to be updated; and update logic to update zero or more components of the storage key based on the comparing.

28. The article of manufacture of claim 27, wherein the control program indicates the one or more selected components by providing one or more masks for the one or more selected components set to indicate whether the one or more selected components are to be updated.

29. The article of manufacture of claim 27, wherein the storage key is associated with a block of storage of the computing environment, and wherein the compare logic comprises logic to compare one or more values of the one or more components to one or more values of a storage key previously associated with the block of storage.

30. The article of manufacture of claim 27, wherein the storage key is associated with a block of storage of the computing environment, and wherein:

the compare logic compares values of an access control and a fetch control to values of an access control and a fetch control of a storage key previously associated with the block of storage, the comparing refraining from performing a comparison on a reference control, should the control program specify updating of the reference control can be bypassed and the comparing refraining from performing a comparison on a change control, should the control program specify updating of the change control can be bypassed; and

the update logic updates at least the access control, should the comparing of the access controls indicate a difference, and the updating updates at least the fetch control, should the comparing of the fetch controls indicate a difference.

31. The article of manufacture of claim 27, wherein the storage key is associated with a block of storage, and wherein the computer readable program code logic further comprises select logic to select the block of storage from a queue, wherein the select logic selects the block of storage from one of: a queue designated to exclusively include blocks of storage with storage keys having one or more storage key components with respective specified values, and a queue having a plurality of regions in which each region of one or more regions of the plurality of regions of the queue is designated to include blocks of storage with storage keys having one or more storage key components with respective specified values.

32. A queue stored in memory of a computing environment and accessed by a program of the computing environment to obtain a block of storage, said queue comprising:

one or more blocks of storage and associated storage keys, wherein each storage key of the associated storage keys has one or more storage key components of respective specified values, wherein a block of storage having a storage key in which at least one storage key component of the one or more storage key components has a different value from the respective specified value is excluded from the queue.

33. The queue of claim 32, wherein the one or more components comprise an access control having a first specified value and a fetch control having a second specified value.