HK1201348B - Method, system and storage medium for improving processing in computing environment - Google Patents

Description

Method, system, and storage medium for facilitating processing in a computing environment

Technical Field

Aspects of the present invention relate generally to processing within a computing environment, and in particular, to facilitating processing associated with shared resources.

Background

One type of resource-shared environment is a virtual environment that includes a host Central Processing Unit (CPU) and one or more guest central processing units. A guest CPU (also referred to as a virtual CPU) is provisioned by a host program (e.g., a host operating system) executing on the host CPU. The host program performs actions to allocate resources from the underlying host configuration and assign those resources to the guest CPUs.

In one particular embodiment, a guest CPU is present when the host CPU enters the interpretive execution mode. At this point, the guest operating system (also referred to herein as a guest program) begins execution on the virtualized CPU while the host program temporarily suspends execution on the host CPU. At the end of the interpreted execution mode, the host program continues execution on the CPU. Linking techniques exist between the host and the client by which the host and client states are saved and restored. Typically, when a host program starts a guest program, the host program is temporarily suspended until the guest program returns. Both the client CPU and the host CPU are different modes of one host CPU.

The host configuration typically includes all of the resources of the computer system. These resources include, but are not limited to, Central Processing Units (CPUs), main memories, and input/output (I/O) devices. In this system, multiple guest CPUs may be supported by a single host CPU. This is achieved by: each client CPU is assigned a period of time called a time slice (timer) to use the host CPU, and then the host CPU is moved to another client CPU for a time slice, and so on. The number of guest CPUs that can be supported by the host CPU varies depending on the capabilities of the host CPU and the desired capabilities to be assigned to each guest CPU.

The client configuration is typically formed of two or more client CPUs and is referred to as a client Multiprocessing (MP) configuration. Each guest CPU may be provisioned by sharing of a separate host CPU or even by sharing a single host CPU. One attribute of this sharing is that: the client CPU may operate for a period of time called a time slice, and then be inactive for some arbitrary period of time. The inactive period varies based on: a priority policy established by the system, the total number of guest CPUs that will share the host CPU, and the particular sharing technology being used.

In such a client multiprocessing system, a program sometimes referred to as a Dispatchable Unit (DU) may be dispatched by a client operating system on a client CPU, and then the host time slice of the dispatchable unit expires during execution of the dispatchable unit. This may place the dispatchable unit in the following condition: such that the dispatchable unit cannot continue on any other client CPU in the client multiprocessing configuration regardless of the availability of any other client CPU. Rather, the dispatchable unit must wait for the unique client CPU to receive its next time slice in order to continue. Based on the sharing technique and the relative priorities of the client configurations, the next time slice may be delayed for a significant period of time. Continuation of the dispatchable unit is not possible even if the client configuration has other client CPUs capable of executing the dispatchable unit (due to the state of the client CPU of the dispatchable unit being saved at the expiration of the previous time slice). The dispatchable unit is inactive until the precise state is available for the guest CPU to resume.

Disclosure of Invention

The shortcomings of the prior art are overcome and advantages are provided through the provision of a computer program product for facilitating processing in a computing environment. The computer program product includes a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method comprises, for example: obtaining, by a program, an indication to install an alert tracking facility within the computing environment, the alert tracking facility providing a grace period to the program to perform a function; receiving, by the program, an alert tracking notification indicating that an alert tracking grace period has begun; and based on the alert tracking notification, initiating, by the program, at least the function during the alert tracking grace period.

Methods and systems relating to one or more aspects of the present invention are also described and claimed herein. Additionally, services relating to one or more aspects of the present invention are also described and may be claimed herein.

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.

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 will be apparent from the following detailed description taken in conjunction with the accompanying drawings.

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

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

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

FIG. 4 depicts one embodiment of the logic associated with client observation of an alert tracking interruption facility, in accordance with an aspect of the present invention;

FIG. 5 depicts one embodiment of the logic associated with host observation of an alert tracking interrupt facility, in accordance with an aspect of the present invention;

FIG. 6 depicts an embodiment of the logic associated with a host handling guest logout, in accordance with an aspect of the present invention;

FIG. 7 depicts one embodiment of an overview of alert tracking interruption facility logic, in accordance with an aspect of the present invention;

8A-8C depict an embodiment of the logic associated with alert tracking interrupt facility processing in accordance with an aspect of the present invention;

FIG. 9 depicts one embodiment of the logic associated with receiving an alert tracking interrupt, in accordance with an aspect of the present invention;

FIG. 10 depicts one embodiment of a format of a diagnostic instruction used, in accordance with an aspect of the present invention;

FIG. 11 depicts an embodiment of a computer program product incorporating one or more aspects of the present invention;

FIG. 12 depicts an embodiment of a host computer system incorporating and using one or more aspects of the present invention;

FIG. 13 depicts another example of a computer system incorporating and using one or more aspects of the present invention;

FIG. 14 depicts another example of a computer system including a computer network that incorporates and uses one or more aspects of the present invention;

FIG. 15 depicts an embodiment of various components of a computer system incorporating and using one or more aspects of the present invention;

FIG. 16A depicts an embodiment of an execution unit of the computer system of FIG. 15 that incorporates and uses one or more aspects of the present invention;

FIG. 16B depicts an embodiment of a branch unit of the computer system of FIG. 15 incorporating and using one or more aspects of the present invention;

FIG. 16C depicts an embodiment of a load/store unit of the computer system of FIG. 15 containing and using one or more aspects of the present invention; and

FIG. 17 depicts an embodiment of an emulated host computer system incorporating and using one or more aspects of the present invention.

Detailed Description

According to aspects of the present invention, a capability is provided for alerting a program (e.g., an operating system) that it has a grace period for executing a function. For example, a program is given a grace period to perform cleanup (e.g., complete, stop, and/or move dispatchable units).

According to another aspect of the invention, a program and/or processor is alerted that it will lose access to a resource (e.g., a shared resource). By way of example, the following alerts are provided to a processor sharing resources with other processors: the processor will lose access to the resource. As another example, a program such as an operating system executing on a shared processor (i.e., the program shares the processor with other programs) alerts it that it will lose its processor resources.

In one particular embodiment, the following capabilities are provided: providing to a guest program executing on a guest CPU provisioned (provisioning) by a host CPU: an alert regarding expiration of a time slice given to the client CPU from the host CPU; or an alert regarding the host's prior execution of the client's time slice. The alert provides a grace period that the client CPU can use to perform certain functions, such as completing execution of the dispatchable unit, stopping the dispatchable unit at a point where the dispatchable unit is re-dispatchable, and/or moving the dispatchable unit to another client CPU.

As used herein, a grace period includes, by way of example, an amount of time, a number of instructions, a number of cycles, and the like. The grace period has a predetermined duration during which one or more functions may be performed.

One embodiment of a computing environment to incorporate and use one or more aspects of the present invention is described with reference to FIG. 1. In this particular embodiment, the computing environment 100 includes multiple processors 102 that share resources 104. Each processor (and/or programs executing on the processor, such as an operating system) is given a certain amount of time, called a time slice, to share resources. By way of example, resources include central processing unit resources, memory, input/output devices or interfaces, and/or other resources. A processor (or program executing on the processor) that has access to the resource is alerted that the processor's access will end and, as a result, the processor (or program) will perform a particular action, such as cleaning, completing a unit of work, stopping a unit of work, moving a unit of work, and so forth.

Another embodiment of a computing environment 200 incorporating and using one or more aspects of the present invention is described with reference to FIG. 2. The computing environment 200 is based, for example, on the International Business Machines CorporationSupplied by (Armonk, New York)Described in 8 months 2010 under the heading "z/Architecture Principles of OperationDisclosure of (Publication No. SA22-7832-08, version nine), which is hereby incorporated by reference in its entirety. In one example, based onIncludes a System offered by International Business Machines Corporation (Armonk, New York)And (4) a server.Andand as mentioned hereinafterAndis a registered trademark of International Business Machines Corporation (Armonk, New York, USA). Other names used herein may be registered trademarks, trademarks or product names of International Business Machines Corporation or other companies.

As one example, the computing environment 200 includes a Central Processor Complex (CPC) 202 that provides virtual machine support. The CPC 202 includes, for example, one or more virtual machines 204 (or logical partitions in another embodiment), one or more central processors 206, at least one host 208 (e.g., a control program such as a hypervisor), and an input/output subsystem 210, each of which is described below. In this example, the virtual machine and the host are included in memory.

As an example, the virtual machines of a CPC support the ability to operate a large number of virtual machines that are each capable of hosting a program such as a virtual machineOr a Linux client operating system 212. Each virtual machine 204 can function as a separate system. That is, each virtual machine can be independently reset, host the guest operating system, and operate with a different program. The operating system or application program executing in the virtual machine appears to be able to access a complete and complete system, but in reality, only a portion of the system is available.

The physical resources of the CPC (e.g., CPUs, memory, I/O devices, etc.) are owned by the host 208, and shared physical resources are assigned by the host to the guest operating systems as needed to meet the processing requirements of the guest operating systems. The interaction between the guest operating system and the physically shared machine resources is controlled by the host, since a large number of guests typically prevent the host from simply partitioning and assigning hardware resources to configured guests.

The central processor 206 is a physical processor resource that may be assigned to a virtual machine. For example, virtual machine 204 includes one or more logical processors, each of which represents all or a share of physical processor resources 206 that may be dynamically allocated to the virtual machine. Virtual machine 204 is managed by host 208. By way of example, the host may be implemented in microcode executing on the processor 206, or may be part of a host operating system executing on the machine. In one example, the host 208 is a processor resource/system manager (PR/SM) supplied by International Business Machines Corporation (Armonk, New York).

Input/output subsystem 210 directs the flow of information between the device and the main storage. The input/output subsystem 210 is coupled to the central processing complex, and in this regard, the input/output subsystem 210 may be part of the central processing complex or separate from the central processing complex. The I/O subsystem relieves the central processor of the task of communicating directly with the I/O devices coupled to the CPC and permits data processing to proceed concurrently with I/O processing.

In one embodiment, a host (e.g., PR/SM) and a processor (e.g., System)) The hardware/firmware interact with each other in a controlled cooperative manner to handle guest operating system operations without the need for transfer of control to/from the guest operating system and the host. The guest operations may be performed directly without host intervention via a facility that allows instructions to be executed for guest interpretation. This facility provides a host-issuable instruction "Start Interpreted Execution (SIE)" that specifies the state of the holding guest (virtual machine) and a control block called a state description of the control. This instruction places the CPU in an interpreted execution mode that directly processes guest instructions and interrupts until a condition occurs that requires host attention. When this condition occurs, the interpretation execution ends and either a host interrupt is presented, or the SIE instruction completes storing details of the encountered condition; this latter action is called interception. An example of interpretation Execution is described in System/370 ExtendedArchitecture/Interactive Execution, 9.1985 (IBM publication No. SA 22-7095-01), which is hereby incorporated by reference in its entirety.

As used herein, firmware includes, for example, microcode, millicode (millicode), and/or macrocode of a processor. Firmware, for example, includes hardware-level instructions and/or data structures used in the implementation of higher-level machine code. In one embodiment, the firmware includes, for example, proprietary code that is typically delivered as microcode including trusted software or as underlying hardware-specific microcode and that controls operating system access to the system hardware.

Another example of a computing environment incorporating one or more aspects of the present invention is depicted in FIG. 3. In this example, an emulated host computer system 300 is provided, the emulated host computer system 300 emulating a host computer 302 of a host architecture. In the emulated host computer system 300, a host processor (CPU)304 is an emulated host processor (or virtual host processor) and is implemented via an emulation processor 306 having a native instruction set architecture that is different from the native instruction set architecture used by the processor of the host computer 302. The emulated host computer system 300 has a memory 308 accessible to the emulation processor 306. In an example embodiment, the memory 308 is partitioned into a main computer memory portion 310 and an emulation routines portion 312. The host computer memory 310 may be used to emulate the programs of the host computer 302 according to the host computer architecture, and may include both a host or hypervisor 314 and one or more virtual machines 316 (similar to similarly-named components in FIG. 2) that execute a guest operating system 318.

The emulation processor 306 executes native instructions of a constructed instruction set of an architecture different from that of the emulation processor 304. For example, native instructions are obtained from simulation routine memory 312. The emulation processor 306 may access host instructions for execution from a program in the host computer memory 310 by using one or more instructions obtained in a sequence and access/decode routine that may decode the accessed host instructions to determine a native instruction execution routine for emulating the function of the accessed host instructions. One host instruction may be, for example, a launch interpreted execution (SIE) instruction by which the host seeks to execute a guest program in a virtual machine. The emulation routine 312 can include support for this instruction and is used to execute a sequence of guest instructions in the virtual machine 316 as defined by this SIE instruction.

By way of example, other facilities defined for the architecture of the host computer system 302 may be emulated by constructed facility routines, including facilities such as general purpose registers, control registers, dynamic address translation and I/O subsystem support, and processor caches. The emulation routines may also utilize functions available in the emulation processor 306, such as general purpose registers and dynamic translation of virtual addresses, to improve the performance of the emulation routines. Dedicated hardware and a offload engine may also be provided to emulate the functions of host computer 302 with coprocessor 306.

According to aspects of the present invention, an alert tracking interruption facility is provided that is usable in many types of computing environments. Although alert tracking interrupt facilities may be used in many types of environments, aspects of the facilities are described herein with reference to a client multiprocessing system. As described above, in a guest multiprocessing system, a guest operating system dispatches dispatchable units (e.g., programs, program code, etc.) on guest central processing units that are hosted by at least one host central processing unit. The host CPU provides a time slice (e.g., an amount of time or other period, such as a number of instructions, a number of cycles, etc.) for the guest CPU during which dispatchable units execute. If a time slice expires during execution of a dispatchable unit, the dispatchable unit may be made to be in the following condition: so that it cannot continue on any other client CPU in the client multiprocessing configuration regardless of the availability of any other client CPU. Rather, the dispatchable unit must wait for the only client CPU to receive its next time slice in order to continue. Based on the particular sharing technique used and the relative priority of the client configuration, the next time slice may be delayed for a significant period of time. Continuation of the dispatchable unit is not possible even if the client configuration has other client CPUs capable of executing the dispatchable unit (due to the state of the client CPU of the dispatchable unit being saved at the expiration of the previous time slice). The dispatchable unit is inactive until the precise state is available to continue with the guest CPU.

It is possible to extend the time slice by granting additional time (or other additional time period such as additional instructions, cycles, etc.), but even with this additional time, the client CPU can extend the execution of the dispatchable unit while still leaving the dispatchable unit in the same non-dispatchable condition because it will be at the expiration time of the normal time slice.

Since the host program is not aware of the control and status used by any client program executing any dispatchable unit, it is not possible to always grant additional time to the guest operating system to clean up its dispatchable unit without establishing a protocol between the host program and the client program. Without the protocol, any additional time granted to the client CPU would be consumed in the main processing and still likely end up with the same dispatchable unit stuck condition. Thus, according to an aspect of the invention, such a protocol is provided.

According to aspects of the invention, a grace period or extended time is provided that includes an alert that indicates to the client program that a particular action should be taken (e.g., completing or making a dispatchable unit re-dispatchable). As an example, a grace period is provided in response to the expiration of a time slice or in response to the host preferentially executing a guest before the time slice expires in order to reclaim the processor for some other higher priority as visible to the host, as described in further detail herein.

As one example, a grace period is provided rather than unconditionally extending a time slice. If a normal time slice has completely expired, a grace period is provided but the next normal time slice is flushed to maintain fairness to all other virtualization clients each having a time slice expectation. If the normal time slice has not expired, the grace period is taken from the remaining normal time. In general, the grace period limits the time (or other period) remaining given to the client CPU and is itself non-extendable. Thus, the client CPU cannot continue execution for an arbitrary and unknown period of time.

At the beginning of the grace period, the client program is notified for the purpose of cleaning up dispatchable units (e.g., completing dispatchable units, stopping dispatchable units, and/or moving dispatchable units). The enforcement of the grace period ensures that: the client CPU does not exceed the granted additional period. The protocol whereby the client program is given a grace period and the client program is notified that the time (or other period) is nearly expired (grace period has begun) is the protocol between the client program and the host program that the client program understands, thereby making this notification worthwhile. That is, the client program will typically fulfill (honor) the notification by making the currently dispatchable unit dispatchable (e.g., mobile dispatchable unit) on another client CPU of the client configuration, if necessary.

Further details regarding the agreement and the alert tracking interruption facility (also referred to as alert tracking or alert tracking facility) are described below with reference to fig. 4-10. The embodiments described with reference to those figures relate to a virtual environment having one or more clients deployed by one or more hosts. However, one or more aspects of the present invention are also directed to other environments, including non-virtual environments in which multiple processors and/or multiple programs share resources.

Referring to FIG. 4, details are described regarding the alert tracking interruption facility protocol as observed by the client. Alert tracking protocols as observed by the client include, for example, a facility installed indication, client registration, notification, and proactive (volentary) exit, each of which is described below.

Referring to FIG. 4, the client program understands the alert tracking protocol and looks for a facility installed indication (step 400). In one example, this indication is a bit stored in a control block (e.g., "Service Call Control Block (SCCB)") that is observed using a read command, such as a "read SCP information" command. After determining that the facility is installed, the client program performs registration (step 402). The registry client communicates to the host program a mechanism regarding the client program's understanding of the alert tracking interrupt facility protocol. In one example, registration is performed using a diagnostic instruction, an example of which is described further below.

In one embodiment, the registration initiated from any of the client central processing units encompasses all of the client central processing units of the multi-processing configuration due to the need for consistent behavior across the client CPUs of the client multi-processing configuration. In a client multiprocessing configuration, the client CPU uses the same main memory and is assumed to operate in what is sometimes referred to as a single image. Thus, the registration of one client CPU is applicable to other client CPUs of the multi-processing environment. In one embodiment, registration is not revocable, and this helps to avoid timing windows, simplifies development and allows improved testability. Even if registered as non-revocable, the client program may determine whether the client program will continue to participate in the protocol. If the client program so selects, the client program need not participate by resetting or having reset one or more enable indicators described below.

After registering the client program for the alert tracking protocol, the client CPU may be notified of the grace period (step 404). For example, the host CPU may alert the client CPU to the expiration of a time slice (or, in another example, an imminent expiration) or the prioritized execution of its time slice. In a particular example, the CPU of a registered client configuration is notified, for example, of the expiration of its normal time slice and provided with an additional period, for example, the beginning of a grace period for cleaning.

After being notified, the client has a constrained amount of time or other period, a grace period (e.g., 50 microseconds in one particular embodiment), to make the dispatchable unit re-dispatchable or make any other appropriate adjustment. If the normal timeslice has ended, a grace period is used to make the dispatchable unit re-dispatchable or make any other appropriate adjustment, e.g., before returning control to the host. If the time slice has not ended, the grace period is used and any remaining portion of the time slice is discarded. Normal account processing occurs for the actual time used by the client CPU.

After the notification is made, the client CPU is within a constrained period (e.g., a limited amount of time), after which the operation of the client CPU is not actively ended. Only one notification is made for each normal time slice period. Thus, the guest CPUs are still subject to ultimate time control constraints that ensure that the underlying shared host CPU can be shared elsewhere, thereby preserving good order and rules in the overall virtualization provided by the host program.

Any of the unique states can be detected by having the client process detectA mechanism to effect the notification. Examples include a unique guest interrupt, an architecturally-defined main memory location that can be set, or an I/O external memory device that can be used for both the host and the guest. The first of the three requires the appropriate client to enable to allow the interrupt. The latter two require periodic checks that are frequent enough not to waste grace periods. In thatIn one particular example, a client interrupt, referred to as a Warning Track Interrupt (WTI), is used as the notification.

After being alerted, the client actively exits its given slot/grace period (step 406). After being notified and making the dispatchable unit re-dispatchable (e.g., stopping the dispatchable unit and moving the dispatchable unit, or completing the dispatchable unit), the client ends the current time slice/grace period. This exit signals to the host program: the client actually follows the protocol. Other reasons may occur for the client to relinquish control and thus return to the host program. Typically, for constrained processing that makes a dispatchable unit re-dispatchable, no conditions for any of these extraneous exits will occur. If the client CPU exits via the alert tracking interrupt protocol within the grace period, a feedback indication is given regarding the next time slice whenever this condition occurs. Thus, the client program knows that it satisfies the time constraint imposed by the grace period.

If the client defers from active exit, execution of the client is preferentially performed by expiration of the grace period. The next time the client CPU is started in the normal time slice, a feedback indication is given so that the client knows that it is delayed. In general, this situation may be used for problem determination in client programs, since the usual grace period allows enough time to clear and proactively exit.

If an external exit occurs, then the next time the client CPU is started within the normal timeslice, it is expected that the active exit will occur quickly. The same feedback mechanism will inform the client program of: the foreign exit has been intervened and therefore provides different information to inform the problem determination.

The active exit is accomplished by any mechanism that allows control to be passed from the client program through the host program, and includes the aforementioned feedback mechanism. The mechanism used will be defined in a specific architecture of the alert tracking interrupt protocol for the host program to recognize client requests. In one example, this mechanism includes diagnostic instructions described below.

In addition to the alert tracking interrupt protocol client observation, in one embodiment, the host also observes the facility, as described in further detail below with reference to FIG. 5.

Referring to FIG. 5, the host recognizes that the facility has installed an indication and reflects the indication to its client (step 500). For example, it may be beneficial for the host to check an installed bit in a control block (e.g., SCCB), and recognize the installed status of the alert tracking protocol (i.e., it is set) and know how the host program can use that status. Thus, the facility indication is reflected to its client. For example, to reflect the facility to the client, the host sets the client control block (e.g., client SCCB) or installed bits in a memory area accessible to the client. If, for any reason, the host program does not want the client to observe the installed state of the alert tracking interrupt facility protocol and does not allow the client to observe the installed state of the alert tracking interrupt facility protocol and use that state, the host program passes an uninstalled indication to the client (e.g., sets a bit visible to the client to zero). Further, in one embodiment, the host program sets the control of the client CPU such that the alert tracking protocol is disabled (e.g., turns off one or more designated bits in the state description of the client CPU).

As the client initiates registration, the host program receives an unsolicited registration request and remembers that the client is registered (step 502). A registration request initiated by any single client CPU is sufficient to register all client CPUs in the client multiprocessing configuration. Thus, the host program enables the alert tracking protocol for all CPUs of the client configuration (step 504). For example, the host program sets one or more designated bits in the state description of the client CPU to enable the alert tracking interrupt facility for the client. It is not necessary to send the registered feedback back to the client. The host will ignore the request and interrupt the facility protocol for alert tracing without enabling the client CPU in the event that the client CPU attempts to register even when the facility is not installed.

After registering and enabling the client for the alert tracking facility, the client may receive notification of the invocation of the protocol (step 506). This may be accomplished in a number of scenarios, as described below.

As one example, when the alert tracking interrupt protocol is enabled for a guest CPU operating in interpreted execution mode on a host CPU (i.e., host CPU X), the host program may initiate the protocol from host CPU Y. That is, the guest CPU has been provisioned by the host CPU X, and the host CPU X is not currently available to the host program. If the host program has to retrieve CPU X, the host program first causes CPU X to exit the interpretation execution mode. That is, the client CPU is stopped, thereby exiting the interpretation execution mode of CPU X. Stopping the client CPU at any arbitrary point without allowing the client CPU itself to actively stop generating the risk of warning of the problem that the interrupt protocol is intended to solve. The alert tracking interrupt protocol allows host CPU Y to request notifications by allowing host program actions to be transformed into notifications in client CPU X (step 506). Since the client program has previously registered, the host program expects to: the client process recognizes the notification and supports the appropriate handling of the notification including the last step of actively ending execution, thus returning control of the host CPU X to the host process. Once this occurs, the host process may proceed, regardless of whether the use of host CPU X may have caused the process to be launched.

The host program notifies the client by, for example, setting any state, setting an indicator (e.g., a bit), or causing an unsolicited asynchronous signal (e.g., an alert tracking interrupt) to be sent to the client. The time of receipt of this notification signal, despite being registered, remains unknown at the client. By registering, the client has just agreed to comply with the protocol if signaled.

In a host single processor system, if one host CPU is in an interpretive execution mode such that the client CPU is operating, there are no other host CPUs to invoke the alert tracking interrupt protocol. However, even in this case, when the host CPU recognizes that a time slice expires while in the interpreted execution mode, the CPU itself may invoke the alert tracking interrupt protocol, and may then grant a grace period and execute a notification.

In another example of a notification, the notification occurs when the host CPU causes a notification defined in the alert tracking interrupt protocol to be sent to the client CPU (due to the host CPU recognizing an internal state change when the host CPU is in the interpreted execution mode). An example of this occurs when the client CPU is enabled for the alert trace interrupt protocol and the host CPU recognizes the end of a time slice. Before signaling the client CPU to relinquish control, the CPU internally grants a grace period to allow the client CPU sufficient time to receive the signal, take appropriate action (e.g., complete or make the current dispatchable unit re-dispatchable), and actively finish. Internally, the host CPU maintains state to indicate: the client CPU has been notified. If the client does not actively end within the grace period, the CPU recognizes this and ends execution of the client, thereby returning control to the host program by ending the interpreted execution mode. In one embodiment, the client cannot determine why the protocol was invoked, but only determines that it is notified of the cleanup and ends. There may be other host theoretical foundations for causing the end of the interpreted execution mode and thus the end of the guest execution. By way of example, the following scenario exists: execution of all client CPUs will be halted to make some coordinated change to the overall client configuration. A multi-processing client configuration does not have some CPUs operating under different rules or assumptions than other CPUs of the client configuration. This asymmetry can produce unpredictable client results.

The host CPU receives the effect of the client CPU having performed an active exit or exit for any other reason (e.g., returning CPU resources to the host) (step 508). If the exit is due to an alert tracing interrupt protocol defined reason, the host program remembers to provide feedback to the guest CPU the next time it is started (regardless of how long it may be). This feedback is a positive ("good") indication, assuming that the client is actively logged out before the grace period expires. If the exit is due to any other reason, no alert trace interrupt protocol feedback occurs the next time the client CPU is started.

If the client is delayed to actively quit; that is, the client performs an action to actively exit, but the grace period has expired, and the execution of the client CPU is preferentially performed by the expiration of the grace period. The next time the client CPU is started in a normal time slice, an exception feedback indication is given so that the client knows that it has delayed its active exit. In general, this situation may be used for problem determination in client programs, since the usual grace period allows enough time to clear and proactively exit.

If an exit other than the active exit of the alert trace interrupt protocol occurs, then the next time the client CPU is started in the normal time slice, no feedback per alert trace protocol is included.

The means for actively withdrawing is by any mechanism that causes control to be passed from the client program to the host program, which is recognized by the host program as a protocol active withdrawal, and which includes the feedback mechanism described above. In one example, the diagnostic instruction is used for active exit. That is, a diagnostic instruction with specific parameters is used to indicate the completion of a time slice. After the diagnostic instruction is issued and executed by the client program, the host program determines whether the exit is on time. Then, when the client is restarted, which is the next sequential instruction after diagnosis, a condition code is provided indicating whether the client is restarted on time. The condition code, for example, is set in a guest Program Status Word (PSW) used to launch the guest at the next sequential instruction. The client may then test the condition code.

The handling by the host of a client active logout is further described with reference to FIG. 6. Initially, when the guest CPU is halted, control returns to the host CPU (step 600). A determination is made as to whether control is returned within the grace period (query 602). If control returns within the grace period, the host program observes the active client exit in an alert trace interrupt protocol and keeps track of good feedback for the next boot of the client CPU, regardless of which host CPU may have configured the client CPU at that time (step 604). This assumes that an alarm trace interrupt facility has been installed. If control does not return within the grace period, the feedback status is not remembered. However, if the client performs an action to actively exit, but the active exit is outside the grace period (INQUIRY 602), then the host program on the host CPU observes the active client exit in a warning track interrupt protocol (even if the client eventually and has to exit involuntarily), and keeps track of bad feedback for the next boot of the client CPU, regardless of which host CPU may have configured the client CPU at that time (STEP 606). Again, this assumes that an alert tracking facility is installed. If not, the feedback state is not memorized.

Thereafter, whether the host remembers good feedback or bad feedback, the host program redirects the host CPU to a priority execution assignment (step 608). That is, the host is redirected to now perform one or more functions that return its resources (CPUs).

In addition, when the client CPU is started up next time in sequence, no matter which host CPU has configured the client CPU, if the feedback state is memorized, the feedback state indication is set before the client CPU is started up (step 610). In one example, the feedback status indication is set in the SIE status description (e.g., in the PSW of the status description) indicating the launch of the next sequential instruction.

Additional details regarding processing associated with an alert tracking interrupt facility are described with reference to fig. 7-9. In particular, FIG. 7 depicts one embodiment of the logic associated with an overview of alert tracking interrupt facility processing; 8A-8C provide details of alert tracking interrupt facility processing according to aspects of the present invention; and figure 9 depicts one embodiment of the logic associated with receiving an alert tracking interrupt.

Referring to FIG. 7, initially a client program (e.g., a client operating system) recognizes that an alert tracking interruption facility has been installed (step 700). In one embodiment, this is accomplished by the client program observing an installed facility indicator, such as a bit, located, for example, in the designated control block. If the client operating system has support to participate in the alert tracking interruption facility, the client operating system recognizes that the alert tracking interruption facility has an installed indicator, and then indicates its ability to participate in the agreement. In one example, this includes registering the client's intent to participate in the alert tracking process (step 702). As described herein, in one example, registration is performed via a diagnostic instruction. At registration time, the guest operating system instructs both the host CPU and the host program that the guest operating system knows how to handle the alert tracking interrupt (WTI), which is an explicit interrupt that provides the following alerts to the guest: for example, a client will lose access to its shared resources, e.g., the client CPU, and, for example, the client should take action with respect to the dispatchable unit that it is currently executing. In one embodiment, registration is a prerequisite for reception of the WTI. If the client is not registered for the alert trace interrupt facility, upon expiration of the client's time slice, the grace period is not provisioned and the client CPU is taken out of the interpreted execution mode.

In one embodiment, the client program has two mechanisms to disable the presence of WTIs even though it is registered. For example, a selected bit in, for example, a Program Status Word (PSW) may be set to zero, which disables the presentation of all external interrupts including WTIs; or a bit in a designated control register (e.g., CR0) may be set to zero to disable WTI only. When both bits are one, the presence of WTI is enabled. If the presence of the WTI remains disabled for the entire WTI grace period, then execution of the client ends without utilizing the WTI, which constitutes an inactive exit.

During the execution of the interpretation by the client CPU, if the client CPU internally recognizes the host CPU timer external interrupt condition (e.g., expired time slice) or priority execution requested by the host program (INQUIRY 704), the internal CPU processing determines whether an alert tracking interrupt process is to be performed (INQUIRY 706) before the host receives control. That is, the internal CPU process checks that the client is enabled for the alert tracking process, and thus determines that the alert tracking process should be included in the process to be executed. If the alert tracking interrupt process is not to be performed, then the interpretation execution by the client is complete (step 708), and control returns to the host program (step 710). Returning to INQUIRY 706, if, however, an alert tracking interrupt process is to be performed, then processing is performed (STEP 712), as described in further detail below.

Further details of embodiments of the alert tracking interrupt process are described with reference to fig. 8A-8C. In this process, a number of control indicators are used including:

an internal control (e.g., G-bit) in the warning trace interrupt facility grace period active, which is not architecturally visible, but is used by internal CPU logic;

an alert tracking interrupt (WTI) presents internal control (e.g., a P bit) indicating that a WTI has been presented to the client when it is 1 and indicating that a WTI has not been presented when it is 0. Similar to internal control in warning track interrupt facility grace period action, WTI presents internal control that is not architecturally visible, but is used by internal CPU logic;

a client-controlled host program executes first (e.g., T bit), which tracks intervention request indicators, for example, for alerts in the client CPU state description; and

when the E indicator is one, there is an enable of the external interrupt. In one example, the E indicator is a bit within the current Program Status Word (PSW).

Referring to FIG. 8A, in one example, a host CPU timer interrupt condition is recognized (e.g., an expired time slice), or a warning tracking intervention request is recognized (e.g., the host wishes to return the CPU resource early; i.e., before the end of the time slice). If a host CPU timer interrupt condition is recognized (INQUIRY 800), a determination is made as to whether the grace period active control indicator is set (e.g., G equals 1?) (INQUIRY 802). If G is not set, then the G indicator is set to, for example, 1 (step 804) and the tracking outage facility grace period will begin. The current value of the host CPU timer (the saved value is referred to herein as the original value) is then saved 806, and the host CPU timer is set to a warning track grace period, e.g., 50 microseconds 808.

Thereafter, a determination is made as to whether the client is enabled for the alert tracking interrupt (INQUIRY 810). In one embodiment, if client level 2 is active, indicating that one client has started another client, client 2 exits the interpreted execution mode with respect to client 1 interrupts, and cancels the client 1 "start interpreted execution" instruction. Thus, the process is at this point client 1. If client 2 is not active, processing continues only with client 1. If the client is enabled for WTI, an alert tracking external interrupt (WTI) is presented to the client (step 812). In one example, this interrupt includes a specific interrupt code that is presented, indicating that it has a grace period for performing one or more functions (e.g., cleanup), if desired.

Additionally, P is set to 1, indicating that a WTI has been presented (step 814). Also, the T bit is set to 1 using the interlock update function (if an intervention request has been initially used, the T bit may already be 1) (step 816). The grace period in the host CPU timer is continuously decremented regardless of whether a WTI is present (step 818). The process then exits (step 820). In one example, the indication to exit this procedure indicates: the CPU has completed warning track interrupt facility current processing and the CPU is returning to other processing as indicated by the CPU's current state.

Returning to query 810, if the client is not enabled for alert tracking interrupts, processing proceeds to step 816. In this example, the client is not enabled for WTI and therefore cannot be presented to the client. However, the T bit is set pending so that it can be detected later when the client is indeed enabled for WTI.

Returning to INQUIRY 800, if not the host CPU timer interrupt condition, an alert trace interrupt request is identified (i.e., host executes first). That is, the T bit in the intervention request field of the state description of the client is 1. Accordingly, a determination is made as to whether the G indicator is set (INQUIRY 850). If the G indicator is not set (e.g., 0), processing continues with step 804. In this case, the condition that T is equal to 1 is the initial reason for starting the WTI procedure. However, if the G bit is set, then a determination is made as to whether P is set (INQUIRY 852). If P is not set (e.g., equal to 0), processing continues with step 810 in an attempt to present a WTI. However, if P is set (e.g., not equal to 0), then the finding that T is equal to 1 after the warning track facility grace period begins has no effect, and the procedure exits (step 854).

Returning to INQUIRY 802, if G is set (e.g., equal to 1), then the client CPU has executed in the grace period, and the expiration of the host CPU timer indicates that the grace period has expired. Thus, the WTI loop has been previously initiated and the grace period has expired. Thus, referring to FIG. 8B, the previously saved original host CPU timer value is reduced by the amount of time actually used during the grace period and then loaded into the host CPU timer (step 860). The interpretation execution mode is exited, step 862, and a host CPU timer external interrupt is presented to the host, step 864 (this exit is in the form of an inactive guest exit).

In addition to the above, WTI analysis may be initiated via certain instructions that enable the CPU for the WTI. For example, referring to fig. 8C, as described herein, monitoring may initially be performed for a number of instructions of the WTI enabled CPU including: for example, a load PSW (extended) instruction followed by a store or system mask instruction may be set to a designated bit in the PSW, and a "load control" may be set to a selected location in a control register. For example, the T bit for potential alarm tracking processing may be checked for interrupt-enabled instructions. If T is 0 (query 880), then there is no WTI and the procedure exits (step 884). If, however, T ═ l, processing continues with query 822.

At query 882, a determination is made as to whether P is set (e.g., equal to 1). If P is set, the process exits (step 884) because an enable has been previously detected. However, if P is not set (e.g., not equal to 1), then another determination is made as to whether G is set (e.g., equal to 1) (query 886). If G is not set, processing continues with step 804 (FIG. 8A). However, if G is set (e.g., equal to 1) (step 886 (FIG. 8C)), processing continues with query 810 in FIG. 8A (step 888) and processing exits.

Additional details of the processing of the alert tracking interrupt are described with reference to FIG. 9. When the guest program receives the alert tracking interrupt, the guest program performs whatever function the guest program is to perform (e.g., an OS function) in order to, for example, make the dispatchable unit of work re-dispatchable (step 900). For example, a client stops a dispatchable unit at a particular point, saves the state of the dispatchable unit, and moves the dispatchable unit to another client CPU, or enables the dispatchable unit to be moved by providing state information, and so forth. The guest operating system signals the guest operating system to be finished (also referred to as an active logout) by signaling the host program that the alert trace clean is complete (step 902). This signal may be any mechanism that causes the client operation to relinquish the remaining time slice. However, the signal is recognized by the host process as a clean part of the protocol. In one example, a clean-up completed function using a diagnostic instruction.

If the client program signals completion of cleaning before the grace period expires (INQUIRY 904), the host program remembers that the client CPU exited in time (step 906). The withdrawal is an active withdrawal. The next time the client CPU is started, the on-time nature of the signal is indicated back to the client CPU (step 908). In one example, the client continues to execute a PSW set to indicate a successful condition code (e.g., condition code 0).

Returning to INQUIRY 904, if the guest program takes too long for any reason, the grace period expires with the host CPU timer decrementing the grace period to zero, thus presenting the host CPU timer external interrupt condition to the CPU. In this case, the CPU recognizes: the client is already in the grace period and is not granted another grace period. Rather, client execution is halted and control reverts to the host program by receiving an external interrupt. Identifying a host program: this termination of the client CPU is an inactive client exit.

The next time the client CPU starts, the client operating system may then signal that the cleanup has completed, albeit now too late. The host process no longer expects to wait for the receipt of a clear completed signal. Thus, the next time the client CPU is started, the too late nature of the signal is indicated back to the client CPU (step 912). In one example, the client's continued execution of the PSW is marked to indicate a late condition that the client will observe at the next boot. The issuance of too-late diagnostic instructions is sometimes referred to as stale diagnostic instructions because they previously missed an exit within the grace period and then exited later for bad reasons.

In one example, after a new startup of the client CPU, the client program may check the signal continuation portion of the protocol for whether a signal has been issued within the grace period. The client program can use this information to investigate: the client process may be delayed for any reason and improvements are made to improve the statistics on more timely future times.

In one embodiment, when the guest is disabled for all external interrupts, instruction execution monitoring of the external interrupts may be enabled. When the client is enabled for external interrupts, WTI enablement is checked. At this point, if WTI is enabled and the P bit is 0, then WTI is presented to the client CPU.

As mentioned above, in one embodiment, a diagnostic function is used to indicate that cleaning is complete or to track down the interrupt facility registration for alerts. For cleaning to be complete, the diagnostic function signals when issued and executed with cleaning parameters: the issuing CPU has performed any desired processing associated with alerting the receipt of the trace external interrupt. When execution is complete, condition codes are set indicating whether or not to allow model dependent time intervals for cleaning to issue a completion after warning of trace interrupts.

With respect to register functions, the diagnostic function signals when issued and executed with register parameters: a configuration understanding warning trace interrupt is issued. When execution is complete, a success condition code is set. The registration status is cleared by a system reset.

One embodiment of a format for a diagnostic instruction is described with reference to FIG. 10. In one embodiment, the diagnostic instructions 1000 include: an operation code 1002 indicating a diagnostic function; first register field 1004 (R)₁) (ii) a Second register field 1006 (R)₃) (ii) a General register field 1008 (B)₂) (ii) a And shift field 1010 (D)₂). In one example, D is₂The contents of the fields being added to the general register B₂The contents of which are described below. The result is not to address the data, but rather to use certain bits (e.g., bits 48 through 63) as an opcode extension. When the opcode is extended to a predetermined value, an alert trace clean is specified to be completed and the time slice is discarded.

In one example, R₃The field is unused and it contains zero. In addition, general purpose register R₁The designated bit of which is unused and will contain zero, and a general register R₁A particular bit of (e.g., bit 63) specifies a flush completed function when zero and a register function when 1.

In logical partitions using shared physical CPUs, this functionality can improve system performance by allowing the physical CPU on which the logical CPU is executing to be assigned to another logical CPU.

In addition to diagnostics, any other SIE exit during the WTI grace interval (for whatever reason) similarly restores the original value of the host CPU timer decremented by the amount of grace period elapsed.

Detailed herein is an alert tracking interrupt facility that, in one embodiment, provides a mechanism by which alert tracking external interrupts may be presented to a CPU in a configuration having shared CPU resources, such as logical partitions. The control program may use the alert trace external interrupt as a signal to make the currently executing dispatchable unit dispatchable on a different CPU on the arrangement.

In one embodiment, a logical (client) processor executing on a physical processor in a time slice receives an alert signal indicating a grace period, e.g., an amount of time before the logical processor will be interrupted (deallocated from a sharable physical processor), thereby enabling completion of work done by the logical processor or movement of work to another logical processor. As an example, the client CPU is signaled: its time slice has expired and the client CPU should preferentially execute the currently dispatchable work unit (DU) so that the currently dispatchable work unit is reassignable on another client CPU. In one example, the warning signal is an interrupt having an interrupt code indicating that the interrupt is a WTI. In another example, the interrupt code includes information about the amount of time or other period of time that the grace period was given.

In one embodiment, the alert tracking interrupt facility may be used in non-virtual environments as well as virtual environments where one program and/or processor shares resources (e.g., CPU resources or other resources) with one or more other programs and/or processors.

In one embodiment where the environment is a virtual environment, from the client's perspective:

1. the client program observes the installed condition of the alert tracking interrupt protocol facility.

2. The client program registers for the alert tracking interrupt protocol.

3. The client CPU receives alert trace notifications according to a particular architecture (e.g., shared memory indication, shared I/O device indication, interrupt).

4. The client program executing on the client CPU performs the applicable processing according to the nature of the client program that has received the notification (the processing of the notification is expected to be unique per operating system).

5. The client CPU relinquishes control according to the alert tracking protocol proactive technique.

6. The next time the client CPU is started, the client program may observe the feedback according to the alert tracking protocol.

Additionally, in one embodiment, from the perspective of the host:

A. the client program observes the installed condition of the alert tracking interrupt protocol facility.

1. The host program obtains an alert tracking interrupt protocol facility installed indication.

2. The host program permanently remembers the installed state of the alert tracking interrupt protocol.

3. The host program indicates the alert tracking protocol installed status to each client configuration.

4. The host program disables the alert tracking protocol in all unregistered client CPUs.

5. The host program is prepared to recognize client alert trace registration requests from each client configuration.

B. The host process recognizes the alert tracking registration request from the client.

1. The host program permanently remembers that the client configuration understands the alert tracking agreement.

2. The host program enables the client for the alert tracking protocol.

C. During normal guest CPU X operation, the corresponding host CPU X is reacquired using the priority execution of the guest CPU X.

The host program in CPU Y signals the client CPU X.

a. According to the alert tracking protocol, CPU X propagates notifications to client CPU X via updates to shared memory locations, updates to shared I/O devices, or interrupts to client CPU X.

D. The client CPU X stops, thereby returning control to the host CPU X.

1. If within the grace period, the host program on CPU X observes the active client exit in an alert tracking protocol and keeps track of good feedback for the next boot of client CPU X, regardless of which host CPU might have built client CPU X at that time.

a. If the exit of client CPU X is not according to the alert tracking protocol within the grace period, the feedback status is not remembered.

2. If not, the host program on CPU X observes the active client exit in the alert tracking protocol and keeps track of bad feedback for the next boot of client CPU X, regardless of which host CPU might have built client CPU X at that time.

a. If not within the grace period but the exit of client CPU X is not according to the alert tracking protocol, then the feedback status is not remembered.

3. The host program on host CPU X redirects CPU X to perform the assignment preferentially.

E. If the feedback status is remembered, then regardless of which host CPU has configured the client CPU X, the next sequential start of the client CPU X sets the feedback indication according to the alert tracking protocol before starting the client CPU X.

In one embodiment, a client processor of a client configuration receives a unique interrupt, the interrupt is defined for a computer architecture, and the meaning of the interrupt is an alert tracking interrupt. The interrupt indicates a specific code that identifies the interrupt as an alert tracking interrupt. The interrupt implies a relatively short time interval called a grace period, gradually leading to the end of the client processor execution.

During the grace period, in one example, the client program is nominally expected to make the current dispatchable unit of work retainable on another client processor, thus avoiding jamming the current client processor waiting for its next normal time slice boot from the host.

In one example, a relatively short interval of time is granted only once per host program launch by the client processor. The time interval is granted from, for example, the existing time interval in which the client processor is executing. Since the granted time interval is allocated from the normal remaining time slice, the time interval does not essentially borrow time, but rather uses a constrained amount of time from the current time interval to ensure that the client processor is indeed preferentially executed for a relatively short period of time.

In another example where the current time slice has expired, the time interval is granted additional time in addition to the existing time interval in which the client processor is executing. The granted time interval is considered by the host program against the expected next sequential normal time interval that the desired guest processor will next execute as consumed by the guest processor. It is still intended to ensure that: the client processor is indeed preferentially executed in a relatively short period of time.

In one example, an interrupt request for an alert tracking event may be generated to inform the program of: the program is nearing the end of the current execution interval on the shared CPU. The interrupt request is a pending condition type generated when registering the configuration and tracking the interrupt facility enabled configuration for warning.

Cooperative processing between programs (e.g., host and guest) optimizes resource sharing (e.g., CPU) among programs (e.g., guest operating systems). One or more aspects provide, for example, better response time with the same CPU utilization. In addition, system serialization is released before the hypervisor is undispatched.

In another embodiment, one or more aspects of the present invention may be used by requests from an operating system to cause individual threads to continue the elapsed time of the improved time-sensitive work. That is, the thread may request additional time or be provided additional time to perform a function.

As will be appreciated by one skilled in the art, one or more aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, one or more aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," module "or" system. Furthermore, one or more aspects of the present invention may take the form of a computer program product as described embodied in one or more computer-readable media having computer-readable program code embodied therein.

Any combination of one or more computer-readable media may be utilized. The computer readable medium may be a computer readable storage medium. For example, a computer readable storage medium may be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Referring now to FIG. 11, in one example, a computer program product 1100 includes, for instance, one or more non-transitory computer-readable storage media 1102 to store computer-readable program code means or logic 1104 thereon to provide and facilitate one or more aspects of the present invention.

Program code embodied on a computer readable medium may be transmitted using an appropriate medium, including but not limited to wireless media, wired media, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for one or more aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language, assembler or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the context of a fully executed remote computer or server, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

One or more aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of one or more aspects of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of program code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition to the above, one or more aspects of the present invention may also be provided, provisioned, deployed, managed, serviced, etc. by a service provider that offers management of customer environments. For example, a service provider can generate, maintain, support, etc., computer program code and/or a computer infrastructure that performs one or more aspects of the present invention for one or more customers. In return, the service provider may collect payment from the customer under a subscription and/or fee agreement, as examples. Alternatively or additionally, the service provider may collect payment from the sale of advertising content to one or more third parties.

In one aspect of the present invention, an application may be deployed for performing one or more aspects of the present invention. As one example, deployment of an application includes providing a computer infrastructure operable to perform one or more aspects of the present invention.

As another aspect of the present invention, a computer infrastructure may be deployed comprising computer readable program code embodied in the computing system, wherein the program code in combination with the computing system is capable of performing one or more aspects of the present invention.

As yet another aspect of the present invention, a program for integrating computer infrastructure, comprising integrating computer readable program code into a computer system, can be provided. The computer system includes a computer-readable medium, wherein the computer medium includes one or more aspects of the present invention. The program code in combination with the computer system is capable of performing one or more aspects of the present invention.

While various embodiments are described above, these embodiments are only examples. For example, computing environments of other architectures may incorporate and use one or more aspects of the present invention. In addition, the grace period may be different than an amount of time, such as a number of instructions or cycles or any other quantifiable value. Many changes and/or additions may be made without departing from the spirit of the invention.

In addition, other types of computing environments may benefit from one or more aspects of the present invention. By way of example, data processing systems suitable for storing and/or executing program code are available that include at least two processors coupled directly or indirectly to memory elements through a system bus. The memory components include, for instance, local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times program code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, DASD, magnetic tape, CDs, DVDs, drive and other memory media, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and ethernet cards are just a few of the available types of network adapters.

Other examples of computing environments that may incorporate and/or use one or more aspects of the present invention are described below.

Referring to FIG. 12, representative components of a host computer system 5000 to implement one or more aspects of the present invention are depicted. The representative host computer 5000 comprises one or more CPUs 5001 in communication with computer memory (i.e., central storage) 5002, and I/O interfaces to storage media devices 5011 and networks 5010 for communicating with other computers or SANs and the like. The CPU5001 conforms to an architecture having a constructed instruction set and constructed functionality. The CPU5001 may have a Dynamic Address Translation (DAT)5003 for converting program addresses (virtual addresses) into real addresses of memory. DAT typically includes a Translation Lookaside Buffer (TLB)5007, which is used to cache translations so that later accesses to blocks of computer memory 5002 do not require the delay of address translation. Typically, a cache 5009 is used between the computer memory 5002 and the processor 5001. The cache 5009 may be a hierarchical cache, having a large cache available to more than one CPU and a smaller, faster (lower level) cache between the large cache and each CPU. In some embodiments, the lower-level cache is split to provide separate lower-level caches for instruction fetching and data accesses. In one embodiment, instructions are fetched from memory 5002 by instruction fetch unit 5004 via cache 5009. Instructions are decoded in the instruction decode unit 5006 and dispatched (in some embodiments, by other instructions) to the instruction execution unit 5008. Typically, several execution units 5008 are used, such as an arithmetic execution unit, a floating point execution unit, and a branch instruction execution unit. Instructions are executed by the execution units to access operands from registers or memory specified by the instructions, as needed. If operands are to be accessed (loaded or stored) from memory 5002, load/store unit 5005 typically handles the access under control of the instruction being executed. The instructions may be executed in hardware circuitry, or in internal microcode (firmware), or by a combination of both.

As noted, the computer system includes information in local (or main) storage, as well as addressing, protection, and reference and change records. Some aspects of addressing include the format of the addresses, the concept of address space, the various types of addresses, and the manner in which addresses of one type are translated to addresses of another type. Some of the primary storages include permanently assigned storage addresses. The main storage provides directly addressable, fast access storage of data for the system. Both data and programs will be loaded into the main storage (from the input device) before they can be processed.

The main storage may include one or more smaller, faster access buffers, sometimes referred to as caches. Caches are typically physically associated with the CPU or I/O processor. In addition to performance, the physical structure and effects of use of dissimilar storage media are generally program unobservable.

Separate caches for instructions and for data operands may be maintained. Information within a cache is maintained in contiguous bytes on an overall boundary called a cache block or cache line (or simply a line). The model provides a "fetch cache attribute" instruction of size in bytes that returns a cache line. The model may also provide "prefetch data" and "prefetch relative length" instructions that enable prefetching of storage into a data or instruction cache or release of data from the cache.

The storage is considered a long horizontal bit string. For most operations, accesses to storage are made in a left-to-right sequence. The bit string is subdivided into eight bit cells. An octet unit is called a byte, which is the basic building block for all information formats. Each byte location in storage is identified by a unique nonnegative integer, which is the address of the byte location, or simply the byte address. The adjacent byte locations have consecutive addresses, starting with 0 on the left side and proceeding in a sequence from left to right. Addresses are unsigned binary integers and are 24, 31, or 64 bits.

Information is transferred between the storage and the CPU or channel subsystem one byte or group of bytes at a time. Unless otherwise specified, for example, inThe byte groups in storage are addressed by the leftmost byte of the group. The number of bytes in a group is implicitly or explicitly specified by the operation to be performed. When used in CPU operations, groups of bytes are referred to as fields. In each byte group, e.g. inIn (1), the numbers are aligned in a sequence from left to right. In thatThe leftmost bits are sometimes referred to as "high order" bits, and the rightmost bits are referred to as "low order" bits. However, the bit number is not a storage address. Only bytes may be addressed. To operate on individual bits of a byte in storage,the entire byte is accessed. Bits in a byte are numbered 0 to 7 from left to right (e.g., inIn (1). The bits in the address may be numbered 8 to 31 or 40 to 63 for a 24-bit address or 1 to 31 or 33 to 63 for a 31-bit address; the bits in the address are numbered 0 to 63 for a 64-bit address. Within any other fixed-length format of a plurality of bytes, the bits that make up the format are numbered consecutively starting from 0. One or more check bits may be transmitted with each byte or with groups of bytes for error detection purposes, and preferably for correction purposes. These check bits are automatically generated by the machine and are not directly programmable. The storage capacity is expressed in terms of the number of bytes. When the length of the stored operand field is implied by the opcode of the instruction, the field is said to have a fixed length, which may be one, two, four, eight, or sixteen bytes. Larger fields may be implied for some instructions. When the length of the operand field is stored not implicitly but explicitly stated, the field is said to have a variable length. The length of the variable-length operand may vary in increments of one byte (or by some instructions, in multiples of two bytes or other multiples). When information is placed in storage, the replacement specifies the contents of only those byte locations included in the field, even though the width of the physical path to storage may be greater than the length of the field being stored.

Some units of information will be at integral boundaries in the store. When the storage address is a multiple of the length in bytes, the boundary is referred to as a whole for the unit of information. Fields of 2, 4,8 and 16 bytes on the overall boundary are given a private name. A halfword (halfword) is a group of two consecutive bytes on a two-byte boundary and is the basic building block of instructions. A word is a group of four consecutive bytes on a four-byte boundary. A doubleword is a group of eight consecutive bytes on an eight-byte boundary. A quadword (quadword) is a group of 16 consecutive bytes on a 16-byte boundary. When the storage address specifies a half word, a doubleword, and a quadword, the binary representation of the address contains one, two, three, or four rightmost zero bits, respectively. The instruction will be on a two byte global boundary. Most instructions do not have boundary alignment requirements for their storage operands.

On devices implementing separate caches for instructions and data operands, significant delays may be experienced if a program is stored onto the cache line from which a subsequently fetched instruction is fetched, regardless of whether the store alters the subsequently fetched instruction.

In one embodiment, the present invention may be practiced by software (sometimes referred to as authorized internal code, firmware, microcode, millicode, picocode, and the like, any of which will be consistent with one or more aspects of the present invention). Referring to FIG. 12, software program code embodying one or more aspects of the present invention may be accessed by the processor 5001 of the host system 5000 from a long term storage media device 5011, such as a CD-ROM drive, tape drive or hard drive. The software program code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM. The program code may be distributed on such media, or may be distributed to users from computer memory 5002 or from storage in a computer system over a network 5010 to other computer systems for use by users of such other systems.

The software program code includes an operating system that controls the function and interaction of various computer components and one or more application programs. Program code is typically paged from storage media device 5011 to relatively high speed computer storage 5002 where the program code is available for processing by processor 5001. Techniques and methods for embodying software program code in memory, on physical media, and/or distributing software program code via a network are well known and will not be discussed further herein. Program code is often referred to as a "computer program product" when generated and stored on tangible media, including, but not limited to, electronic memory modules (RAM), flash memory, Compact Discs (CD), DVDs, magnetic tape, and the like. The computer program product medium is typically readable by processing circuitry in a preferred computer system for execution by the processing circuitry.

FIG. 13 illustrates a representative workstation or server hardware system in which one or more aspects of the present invention may be practiced. The system 5020 of fig. 13 comprises a representative underlying computer system 5021, such as a personal computer, workstation or server, including optional peripheral devices. The underlying computer system 5021 comprises one or more processors 5026 and a bus for connecting the processor 5026 with the other components of the system 5021 and for enabling communication between the processor 5026 and the other components of the system 5021 in accordance with known techniques. For example, a bus connects the processor 5026 to memory 5025 and long-term storage 5027, where the long-term storage 5027 may comprise a hard disk drive (including, for example, any of magnetic media, CDs, DVDs, and flash memories) or a tape drive. The system 5021 may also include a user interface adapter that connects the microprocessor 5026 via the bus to one or more interface devices, such as a keyboard 5024, a mouse 5023, a printer/scanner 5030, and/or other interface devices, which may be any user interface device such as a touch-sensitive screen, a digital keypad (entry pad), etc. The bus also connects a display device 5022, such as an LCD screen or monitor, to the microprocessor 5026 via a display adapter.

The system 5021 may communicate with other computers or networks of computers by way of a network adapter capable of communicating 5028 with a network 5029. Example network adapters are communications channels, token rings, ethernet networks, or modems. Alternatively, the system 5021 may communicate using a wireless interface, such as a Cellular Digital Packet Data (CDPD) card. The system 5021 can be associated with these other computers in a Local Area Network (LAN) or a Wide Area Network (WAN), or the system 5021 can be a client in a client/server configuration with another computer, and so on. All of these configurations, as well as appropriate communication hardware and software, are known in the art.

Fig. 14 illustrates a data processing network 5040 in which one or more aspects of the present invention may be practiced. Data processing network 5040 may include a plurality of individual networks, such as wireless networks and wired networks, each of which may include a plurality of individual workstations 5041, 5042, 5043, 5044. Additionally, one or more LANs may be included, where a LAN may include a plurality of intelligent workstations coupled to the host processor, as will be appreciated by those skilled in the art.

Still referring to fig. 14, the network may also include mainframe computers or servers, such as a gateway computer (client server 5046) or application server (remote server 5048 which may access a data repository and may also be accessed directly from a workstation 5045). The gateway computer 5046 serves as an entry point into each individual network. A gateway is required when connecting one network connection protocol to another. The gateway 5046 may be coupled to another network (e.g., the internet 5047), preferably by way of a communication link. The gateway 5046 may also be directly coupled to one or more workstations 5041, 5042, 5043, 5044 using a communications link. IBM eServer available from International Business Machines Corporation may be utilized^TMSystemThe server implements a gateway computer.

Referring concurrently to fig. 13 and 14, software programming code which may embody one or more aspects of the present invention may be accessed by the processor 5026 of the system 5020 from long-term storage media 5027, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM. The program code may be distributed on such media, or may be distributed to users 5050, 5051 from memory or from storage on one computer system over a network to other computer systems for use by users of such other systems.

Alternatively, the programming code may be embodied in the memory 5025 and accessed by the processor 5026 using the processor bus. The programming code includes an operating system that controls the function and interaction of the various computer components and one or more application programs 5032. The program code is typically paged from the storage medium 5027 to high speed memory 5025 where the program code is available for processing by the processor 5026. Techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software programming code over a network are well known and will not be discussed further herein. Program code is often referred to as a "computer program product" when generated and stored on tangible media, including, but not limited to, electronic memory modules (RAM), flash memory, Compact Discs (CD), DVDs, magnetic tape, and the like. The computer program product medium is typically readable by processing circuitry in a preferred computer system for execution by the processing circuitry.

The most readily available cache for the processor (typically faster and smaller than the other caches of the processor) is the lowest level (L1 or level one) cache, and the main storage (main memory) is the highest level cache (L3 if there are 3 levels). The lowest level cache is often divided into an instruction cache (I-cache) that holds the machine instructions to be executed, and a data cache (D-cache) that holds the data operands.

Referring to fig. 15, an exemplary processor embodiment is depicted for the processor 5026. Typically, one or more levels of cache 5053 are used to buffer memory blocks in order to improve processor performance. Cache 5053 is a cache that holds cache lines of memory data that are most likely to be used. Typical caches are 64, 128 or 256 bytes of memory data. In addition to being used to cache data, separate caches are often used to cache instructions. Cache coherency (synchronization of copies of rows in memory and cache) is often provided by various "snoop" algorithms well known in the art. The main memory storage 5025 of the processor system is often referred to as a cache. In a processor system having 4 levels of cache 5053, the primary storage 5025 is sometimes referred to as a level 5(L5) cache, since it is typically faster and maintains only a portion of the non-volatile storage (DASD, tape, etc.) available to the computer system. The main storage 5025 "caches" pages of data that are paged in and out of the main storage 5025 by the operating system.

Program counter (instruction counter) 5061 tracks the address of the current instruction to be executed.The program counter in the processor is 64 bits and can be truncated to 31 or 24 bits to support the previous addressing restrictions. The program counter is typically embodied in a Program Status Word (PSW) of the computer such that the program counter persists during context switches. Thus, an in-progress program having a program counter value may be interrupted by, for example, the operating system (context switching from the program environment to the operating system environment). The PSW of the program maintains a program counter value when the program is not active and uses the program counter of the operating system (in the PSW) while the operating system is executing. Typically, the program counter is incremented by an amount equal to the number of bytes of the current instruction. The length of Reduced Instruction Set Computing (RISC) instructions is typically fixed, while the length of Complex Instruction Set Computing (CISC) instructions is typically variable. IBMThe instruction is a CISC instruction having a length of 2, 4 or 6 bytes. For example, the program counter 5061 is modified by a context switch operation or a branch token operation of a branch instruction. In a context switch operation, the current program counter value is saved in a program status word along with other status information about the program being executed (such as condition code), and the new program counter value is loaded to point to the instruction of the new program module to be executed. Branch token operations are performed to permit a program to make decisions or loop within the program by loading the results of branch instructions into the program counter 5061.

Generally, instruction fetch unit 5055 is used to fetch instructions on behalf of processor 5026. The fetch unit fetches the "next sequential instruction", the target instruction of the branch token instruction or the initial instruction of the program after the context switch. Modern instruction fetch units often use prefetch techniques to speculatively prefetch instructions based on the likelihood that a prefetch instruction may be used. For example, the fetch unit may fetch 16 bytes of instructions including the next sequential instruction and additional bytes of other sequential instructions.

The fetched instructions are then executed by the processor 5026. In one embodiment, the fetched instructions are passed to dispatch unit 5056 of the fetch unit. The dispatch unit decodes the instruction and forwards information about the decoded instruction to the appropriate units 5057, 5058, 5060. Execution unit 5057 will typically receive information about decoded arithmetic instructions from instruction fetch unit 5055, and will perform arithmetic operations on operands based on the opcode of the instruction. Operands are preferably provided to the execution units 5057 from memory 5025, from architected registers 5059, or from real-time fields of the instruction being executed. The results of the execution are stored as they are stored in memory 5025, registers 5059, or other machine hardware (such as control registers, PSW registers, and the like).

Processor 5026 typically has one or more units 5057, 5058, 5060 for performing the function of instructions. Referring to fig. 16A, execution units 5057 may communicate with architected general registers 5059, decode/dispatch units 5056, load store units 5060, and other processor units 5065 by way of interfacing logic 5071. The execution unit 5057 may use a number of register circuits 5067, 5068, 5069 to hold information that an Arithmetic Logic Unit (ALU)5066 is to operate on. The ALU performs arithmetic operations such as addition, subtraction, multiplication, and division, as well as logical functions such as AND, OR, and XOR, rotation, and shift. Preferably, the ALUs support dedicated operations that design dependencies. For example, other circuitry may provide other constructed facilities 5072 that include condition codes and repair support logic. Typically, the result of the ALU operation is held in an output register circuit 5070, which output register circuit 5070 may forward the result to a variety of other processing functions. Many configurations of processor units exist, but the description of the invention is intended only to provide a representative understanding of one embodiment.

For example, an ADD (ADD) instruction will be executed in an execution unit 5057 having arithmetic and logical functionality, while a floating point instruction, for example, will be executed in floating point execution with dedicated floating point capabilities. Preferably, the execution unit operates on the operands identified by the instruction by performing the function defined by the opcode. For example, an ADD (ADD) instruction may be executed by the execution unit 5057 on operands found in two registers 5059 identified by register fields of the instruction.

The execution unit 5057 performs arithmetic addition on two operands and stores the result in a third operand, where the third operand may be a third register or one of the two source registers. The execution unit preferably utilizes an Arithmetic Logic Unit (ALU)5066, the Arithmetic Logic Unit (ALU)5066 being capable of performing a variety of logic functions such as shift, rotate, And (add), Or (Or) And exclusive Or (XOR), as well as a variety of algebraic functions including any of addition, subtraction, multiplication, division. Some ALUs 5066 are designed for scalar operations and some ALUs 5066 are designed for floating point. Depending on the architecture, the data may be Big Endian (where the least significant byte is at the most significant byte address) or Little Endian (Little Endian) where the least significant byte is at the least significant byte address. IBMIs a big endian. Depending on the architecture, the signed field may be sign and magnitude (1's complement or 2's complement). The 2's complement is advantageous because: the ALU does not need to be designed with subtraction capability since negative or positive values in the 2's complement only require addition within the ALU. For example, numbers are often described in shorthand, where a 12-bit field defines the address of a 4,096 byte block, and is typically described as a 4Kbyte block.

Referring to FIG. 16B, branch instruction information for executing branch instructions is typically sent to the branch unit 5058, and the branch unit 5058 often uses branch prediction algorithms, such as the branch history table 5082, to predict the outcome of a branch before other conditional operations are completed. The target of the current branch instruction is fetched and speculatively executed before the conditional operation completes. When the conditional operation is completed, the speculatively executed branch instruction is either completed or discarded based on the condition of the conditional operation and the speculative result. A typical branch instruction may test the condition code and branch to a target address if the condition code satisfies the branch requirement of the branch instruction, which may be calculated based on a number of digits (including one) found, for example, in a register field or a real-time field of the instruction. The branch unit 5058 may employ an ALU 5074, the ALU 5074 having a plurality of input register circuits 5075, 5076, 5077 and an output register circuit 5080. For example, the branch unit 5058 may communicate with general registers 5059, decode dispatch unit 5056, or other circuitry 5073.

For example, execution of a group of instructions may be interrupted for a variety of reasons, including content context switching initiated by the operating system, program exceptions or errors causing content context switching, I/O interrupt signals causing content context switching, or multi-threaded activity (in a multi-threaded environment) of multiple programs. Preferably, the context switching action saves information about the currently executing process and then loads state information about another process being invoked. For example, state information may be saved in hardware registers or in memory. The state information preferably includes a program counter value pointing to the next instruction to be executed, condition codes, memory translation information, and constructed register contents. Content context switching activity may be trained by hardware circuitry, applications, operating system programs, or firmware code (microcode, picocode, or authorized internal code (LIC)), alone or in combination.

The processor accesses operands according to the instruction defined method. An instruction may use the value of a portion of the instruction to provide a real-time operand, which may provide one or more register fields that explicitly point to general purpose registers or special purpose registers (e.g., floating point registers). The instruction may utilize an implicit register identified by the opcode field as an operand. The instruction may use the memory location for operands. The memory location of the operand may be provided by a register, a real-time field, or a combination of a register and a real-time field, such as byA long displacement facility instance where an instruction defines a base register, an index register, and a real-time field (displacement field) that are added together to provide, for example, the address of an operand in memory. Unless otherwise indicated, a location in main memory (primary storage) is generally implied herein.

Referring to FIG. 16C, the processor uses load/store unit 5060 to access storage. The load/store unit 5060 may perform a load operation by obtaining the address of the target operand in memory 5053 and loading the operand in the register 5059 or another memory 5053 location, or may perform a store operation by obtaining the address of the target operand in memory 5053 and storing data obtained from the register 5059 or another memory 5053 location in the target operand location in memory 5053. The load/store unit 5060 may be speculative and may access memory in a sequence that is out-of-order with respect to the instruction sequence, however, the load/store unit 5060 maintains an appearance to programs that execute instructions in-order. The load/store unit 5060 may communicate with general registers 5059, decode/dispatch unit 5056, cache/memory interface 5053 or other components 5083, and includes various register circuits, ALUs 5085 and control logic 5090 to calculate storage addresses and provide pipeline sequencing to keep operations in order. Some operations may be out-of-order, but the load/store unit provides functionality such that out-of-order operations appear to a program to have been executed in order, as is well known in the art.

Preferably, the addresses that are "seen" by the application are often referred to as virtual addresses. Virtual addresses are sometimes referred to as "logical addresses" and "effective addresses". These virtual addresses are virtual in that: which are redirected to a physical memory location by one of a variety of Dynamic Address Translation (DAT) techniques including, but not limited to, simply prefixing a virtual address with an offset value, translating the virtual address via one or more translation tables, preferably alone or in combinationPreferably includes at least one segment table and a page table, preferably the segment table having entries pointing to the page table. In thatIn one embodiment, a translation hierarchy is provided that includes a region first table, a region second table, a region third table, a segment table, and an optional page table. The performance of address translation is often improved by utilizing a Translation Lookaside Buffer (TLB) that contains entries that map virtual addresses to associated physical memory locations. These entries are generated when DAT uses the translation table to translate a virtual address. Subsequent use of the virtual address may then utilize the entry of the fast TLB rather than the slow sequential translation table access. TLB content may be managed by a variety of replacement algorithms, including Least Recently Used (LRU).

In the case where the processors are processors of a multi-processor system, each processor has the responsibility of keeping shared resources such as I/O, cache, TLB, and memory interlocked to achieve coherency. Generally, "snooping" techniques will be used in maintaining cache coherency. In a snooping environment, each cache line may be marked as being in any one of a shared state, an exclusive state, a changed state, an invalid state, and the like, in order to facilitate sharing.

For example, an I/O unit 5054 (fig. 15) provides a means for the processor to attach to peripheral devices including tapes, optical disks, printers, displays, and networks. The I/O cells are often presented to the computer program by a software driver. In a form such as is commercially available fromSystem ofIn the mainframe computer, the channel adapter and the open system adapter are I/O units of the mainframe computer that provide communication between the operating system and peripheral devices.

In addition, other types of computing environments may benefit from one or more aspects of the present invention. As an example, as mentioned herein, an environment may include an emulator (e.g., software or other emulation mechanisms) in which a particular architecture (including, for example, instruction execution, architected functions such as address translation, and architected registers) or a subset thereof (e.g., on a native computer system having a processor and memory) is emulated. In this environment, one or more simulation functions of a simulator may implement one or more aspects of the present invention, even though the computer executing the simulator may have a different architecture than the capabilities being simulated. As one example, in emulation mode, a particular instruction or operation being emulated is decoded, and appropriate emulation functions are built to implement the respective instruction or operation.

In a simulation environment, a host computer includes, for example: a memory storing instructions and data; an instruction fetch unit that fetches instructions from memory and, optionally, provides local buffering of fetched instructions; an instruction decode unit that receives the fetched instruction and determines the type of instruction that has been fetched; and an instruction execution unit that executes the instructions. The executing may include: loading data from a memory into a register; storing data from the register back to the memory; or perform some type of arithmetic or logical operation (as determined by the decode unit). In one example, each unit is implemented in software. For example, the operations performed by these units are implemented as one or more subroutines within emulator software.

More particularly, in a mainframe computer, architected machine instructions are often used by programmers (today often "C" programmers) by compiling application programs. The instructions stored in the storage medium may be native toIn a server or in a machine executing other architectures. Can be in the present and futureLarge computer server neutralizationIn thatOther machines (e.g., Power System servers and systems)Server) to emulate the instructions. Can be used byAMD^TMAnd other manufacturers' hardware, execute instructions in machines that execute Linux on a wide variety of machines. Is based onIn addition to the hardware execution, Linux can also be used, as well as machines using simulations by Hercules, UMX, or FSI (Fundamental Software, Inc.), where the execution is substantially in emulation mode. In emulation mode, emulation software is executed by the native processor to emulate the architecture of the emulated processor.

A native processor typically executes emulation software that contains firmware or a native operating system to perform a simulation of the emulated processor. The emulation software is responsible for fetching and executing instructions of the emulated processor architecture. The emulation software maintains an emulation program counter to track instruction boundaries. The emulation software may fetch one or more emulated machine instructions at a time and convert the one or more emulated machine instructions into a group of corresponding native machine instructions for execution by the native processor. These translated instructions may be cached so that faster translations may be achieved. Nevertheless, the emulation software maintains the architectural rules of the emulated processor architecture in order to ensure that the operating system and application programs written for the emulated processor operate correctly. In addition, the emulation software will provide the resources identified by the emulation processor architecture, including, but not limited to, control registers, general purpose registers, floating point registers, dynamic address translation functions including, for example, segment and page tables, interrupt mechanisms, context switching mechanisms, time of day (TOD) clocks, and architected interfaces to the I/O subsystem, such that an operating system or application designed to execute on an emulated processor may execute on a native processor with emulation software.

The specified instruction being emulated is decoded and a subroutine is called to perform the function of the respective instruction. The emulation software functions that emulate the functions of an emulation processor are implemented, for example, as follows: a "C" subroutine or driver, or some other method of providing a driver for specified hardware that would be within the skill of one in the art after understanding the description of the preferred embodiment. Various software and hardware emulation patents, including but not limited to the following, describe a number of known ways to achieve instruction formats architected for different machines for emulation of a target machine that may be used by those skilled in the art: U.S. patent certificate No. 5,551,013 entitled "Multiprocessor for Hardware Emulation" to Beausoleil et al; and U.S. patent certificate No. 6,009,261 entitled "Preprocessing of Stored Target routes for simulating incorporated Instructions on a Target Processor" to Scalazi et al; and U.S. patent certificate No. 5,574,873 entitled "Decoding Guest Instruction to direct Access Instructions of the Guest Instructions" by Davidian et al; and U.S. patent certificate No. 6,308,255 entitled "symmetric Multiprocessing Bus and chip use for processor Support Non-Native Code to Run in a System" by Gorishek et al; and U.S. patent certificate No. 6,463,582 entitled "Dynamic Optimizing Object code Transformer for Architecture implementation and Dynamic Optimizing Object code transformation Method" by Lethin et al; and U.S. patent certificate No. 5,790,825 entitled "Method for simulating guide measurements on a Host Computer Through Dynamic Recompatibilities of Host measurements" by Eric Trout, each of which is hereby incorporated by reference herein in its entirety; and many other patent certificates.

In FIG. 17, an example of an emulated host computer system 5092 is provided that emulates the host computer system 5000' of the host architecture. In the emulated host computer system 5092, the host processor (CPU)5091 is an emulated host processor (or virtual host processor), and includes an emulated processor 5093 having a native instruction set architecture that is different from the native instruction set architecture of the processor 5091 of the host computer 5000'. The emulation host computer system 5092 has memory 5094 accessible by an emulation processor 5093. In an example embodiment, memory 5094 is partitioned into a host computer memory 5096 portion and an emulation routines 5097 portion. The host computer memory 5096 may be used to emulate the programs of the host computer 5092 according to the host computer architecture. The emulation processor 5093 executes native instructions of a constructed instruction set of an architecture other than that of the emulation processor 5091, which native instructions are obtained from emulation routines memory 5097 and which host instructions are accessible for execution by a program in host computer memory 5096 using one or more instructions obtained in a sequence & access/decode routine which decodes the accessed host instructions to determine a native instruction execution routine for emulating the function of the accessed host instructions. For example, other facilities defined for the architecture of the host computer system 5000' may be emulated by constructed facility routines, including facilities such as general purpose registers, control registers, dynamic address translation and I/O subsystem support and processor caches. The emulation routines may also take advantage of functions available in emulation processor 5093, such as dynamic translation of general purpose registers and virtual addresses, to improve the performance of the emulation routines. Dedicated hardware and offload engines may also be provided to emulate the functions of the host computer 5000' with the coprocessor 5093.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of one or more aspects of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims (24)

1. A computer-implemented method for facilitating processing in a computing environment, the method comprising:

obtaining, by a program, an indication that an alert tracking facility has been installed within a computing environment, the alert tracking facility providing an alert tracking grace period to the program to perform a function;

initiating, by the program, registration of the program with the alert tracking facility based on obtaining the indication that the alert tracking facility is installed, the registration including an unsolicited registration request indicating that the program understands an agreement of the alert tracking facility and is willing to participate in the alert tracking facility;

receiving, by the program, an alert tracking notification indicating that the alert tracking grace period has begun; and

based on the alert tracking notification, at least the function is initiated by the program during the alert tracking grace period.

2. The method of claim 1, wherein the program is initiated for the alert tracking facility based on the registration.

3. The method of claim 1, wherein the warning track notification comprises an interrupt in which shared resources assigned to the program are released after expiration of the warning track grace period.

4. The method of claim 1, wherein the function comprises one of:

a dispatchable unit that completes execution on a processor on which the program is executing; or

Such that the dispatchable unit may be reassigned on another processor of the computing environment.

5. The method of claim 1, wherein the program is a client program that accesses shared resources of the computing environment during a time slice provided to a client central processing unit on which the client program executes, the alert tracking grace period being distinct from the time slice.

6. The method of claim 5, wherein the warning track grace period causes the time slice to terminate prematurely.

7. The method of claim 5, wherein the warning track grace period provides a period of time for performing the function in addition to the time slice.

8. The method of claim 1, wherein the method further comprises instructing, by the process, completion of the function during the warning track grace period.

9. The method of claim 8, wherein the method further comprises receiving, by the program, an indication that the function is completed during the warning track grace period when the program next executes.

10. A computer system for facilitating processing in a computing environment, the computer system comprising:

a memory; and

a processor in communication with the memory, wherein the computer system is configured to perform a method comprising:

obtaining, by a program, an indication that an alert tracking facility has been installed within a computing environment, the alert tracking facility providing an alert tracking grace period to the program to perform a function;

initiating, by the program, registration of the program with the alert tracking facility based on obtaining the indication that the alert tracking facility is installed, the registration including an unsolicited registration request indicating that the program understands an agreement of the alert tracking facility and is willing to participate in the alert tracking facility;

receiving, by the program, an alert tracking notification indicating that the alert tracking grace period has begun; and

based on the alert tracking notification, at least the function is initiated by the program during the alert tracking grace period.

11. The computer system of claim 10, wherein the program is initiated for the alert tracking facility based on the registration.

12. The computer system of claim 10, wherein the function comprises one of:

a dispatchable unit that completes execution on a processor on which the program is executing; or

Such that the dispatchable unit may be reassigned on another processor of the computing environment.

13. The computer system of claim 10, wherein the program is a client program that has access to shared resources of the computing environment during a time slice provided to a client central processing unit on which the client program executes, the warning-tracking grace period being distinct from the time slice.

14. The computer system of claim 13, wherein the warning-tracking grace period causes the timeslice to terminate prematurely.

15. The computer system of claim 13, wherein the warning track grace period provides a period of time for performing the function in addition to the time slice.

16. A computer-readable storage medium for facilitating processing in a computing environment, readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method, the method comprising:

obtaining, by a program, an indication that an alert tracking facility has been installed within a computing environment, the alert tracking facility providing an alert tracking grace period to the program to perform a function;

initiating, by the program, registration of the program with the alert tracking facility based on obtaining the indication that the alert tracking facility is installed, the registration including an unsolicited registration request indicating that the program understands an agreement of the alert tracking facility and is willing to participate in the alert tracking facility;

receiving, by the program, an alert tracking notification indicating that the alert tracking grace period has begun; and

based on the alert tracking notification, at least the function is initiated by the program during the alert tracking grace period.

17. The computer readable storage medium of claim 16, wherein the program is initiated for the alert tracking facility based on the registration.

18. The computer-readable storage medium of claim 16, wherein the warning track notification includes an interrupt in which shared resources assigned to the program are released after the warning track grace period expires.

19. The computer-readable storage medium of claim 16, wherein the function comprises one of:

a dispatchable unit that completes execution on a processor on which the program is executing; or

Such that the dispatchable unit may be reassigned on another processor of the computing environment.

20. The computer readable storage medium of claim 16, wherein the program is a client program that accesses shared resources of the computing environment during a time slice provided to a client central processing unit on which the client program executes, the alert tracking grace period being distinct from the time slice.

21. The computer-readable storage medium of claim 20, wherein the warning-tracking grace period causes the time slice to terminate prematurely.

22. The computer readable storage medium of claim 20, wherein the warning track grace period provides a period of time for performing the function in addition to the time slice.

23. The computer readable storage medium of claim 16, wherein the method further comprises indicating, by the program, completion of the function during the alert tracking grace period.

24. The computer readable storage medium of claim 23, wherein the method further comprises receiving, by the program, an indication that the function is complete during the warning track grace period when the program next executes.