Patent Grant
8448176
This invention relates, in general, to heterogeneous computing environments, and in particular, to executing work units within such environments.
Work units, such as applications, jobs, computer programs or portions thereof, are assigned to processors for execution. In multiprocessor computing environments that include a plurality of symmetric processors, the assignment of work units to processors is less complex than in those multiprocessor computing environments that include asymmetric processors. If the processors are symmetrical, and thus, have the same features, then a work unit can execute on any of the processors, assuming there are available resources. However, if the processors are asymmetrical, and thus, do not have the same features, then a particular work unit may be unable to execute on a particular processor. That is, if a work unit needs a feature that is only present on some of the processors, then the work unit will have to execute on a processor having that feature.
The assignment of work units to processors in multiprocessor computing environments having asymmetric processors can be difficult, tedious, and error prone. This is because of the expansive amount of information that needs to be tracked and considered in properly assigning work units to processors for execution.
The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a computer program product for facilitating execution of work units in a computing environment. The computer program product comprises a storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method includes, for instance, analyzing, by an analyzer executing on a processor, one or more resource requirements of a work unit to be executed; determining, based on the analyzing, whether the work unit is to be executed on the processor or an offload processing system different from the processor, the offload processing system and processor being heterogeneous of one another; obtaining, responsive to the determining indicating the work unit is to be executed on the offload processing system, an indication of one or more offload processing systems satisfying one or more criteria for execution of the work unit; checking whether at least one offload processing system of the indication of one or more offload processing systems has sufficient resources to execute the work unit; selecting, responsive to the checking specifying at least one offload processing system that has sufficient resources, a selected offload processing system to execute the work unit; and assigning the work unit to be executed on the selected offload processing system for execution, wherein the selected offload processing system has at least one of a different operating system, a different architecture or a different external attachment from the processor.
Methods and systems relating to one or more aspects of the present invention are also described and claimed herein. Further, 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.
One or more aspects of the present invention are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
In accordance with an aspect of the present invention, a capability is provided for transparently offloading individual work units from a main processor to a suitable offload processing system for execution. In one example, this re-assignment of a work unit includes determining the requirements of the work unit, including, for instance, the hardware and software requirements; matching those requirements against a set of offload processing systems with an arbitrary set of available resources; and determining if a suitable offload processing system is available. If a suitable offload processing system is available, the work unit is assigned to execute on that offload processing system with no changes to the work unit itself. Otherwise, the work unit may execute on the main processor or wait to be executed on an offload processing system.
One embodiment of a computing environment to incorporate and use one or more aspects of the present invention is described with reference to
An offload processing system may include one processor and its external attachments, if any (e.g., storage (e.g., DASD, tape, etc.) or other attachments), or a system having a plurality of processors and its attachments, if any (e.g., a mainframe computer with tightly coupled processors or other types of systems). In this example, one or more of the offload processing systems are heterogeneous from processor 102. An offload processing system 104 that is heterogeneous from processor 102 has, for instance, a different operating system, a different architecture, and/or one or more different external attachments than processor 102. As examples, the operating system may be AIX® or Linux (instead of, for instance, z/OS® executed on main processor 102), and/or the architecture may be PowerPC® or Intel®. As a further example, the offload processing system may have a certain tape drive or other external feature not included with the main processor. Many other examples exist. The offload processing system is heterogeneous from the main processor if, for instance, it has at least one feature different from the main processor. The offload processing systems may be different from one another or similar. In one example, there are many offload processing systems, some of which are homogonous to one another and others of which are different. AIX®, z/OS® and PowerPC® are registered trademarks of International Business Machines Corporation, Armonk, N.Y.; and Intel® is a registered trademark of Intel Corporation.
In this particular example, the offload processing systems are loosely coupled to the main processor. That is, the offload processing systems may share a communications network (e.g., network connection, memory, or direct access storage as a communications medium), but, otherwise, there is an absence of sharing of resources (e.g., it is not necessary for them to share additional memory or other peripheral devices with the main processor). The trade-off between sharing additional resources or not is the increase in cost and complexity required to permit sharing versus the reduced performance or offload capability if required resources are not available. For example, sharing Network Attached Storage (NAS) is relatively cheap and multiple offload processing systems and main processors could share access. Similarly, network connections are relatively easy and not costly. However, access to legacy tape drives or DASD is more costly or, given certain architectures, cost prohibitive.
Further details regarding main processor 102 are described with reference to
In one example, JCL analyzer 130 and step analyzer 132 are part of a job entry subsystem (JES) of z/OS®. JES is the component of the operating system that handles receiving work units into the operating system, scheduling them for processing, and controlling their output processing. In other embodiments, the JCL analyzer and/or step analyzer are not part of JES. Use of the JCL analyzer and the step analyzer are described in further detail below.
In accordance with an aspect of the present invention, a determination is made as to whether a particular work unit is to be executed on the main processor or offloaded to an offload processing system to be executed thereon. In one particular example, the work unit is part of an application that includes one or more work units. The application begins executing on processor 102, and for each work unit (or a subset thereof), a determination is made as to whether the work unit is to be executed on the main processor (i.e., the processor on which the application or work unit was initiated) or an offload processing system. This decision process is further described with reference to
Referring to
Thereafter, a determination is made as to whether there are one or more offload processing systems that meet specified criteria for execution of the work unit. That is, are there one or more offload processing systems that have the hardware and software requirements needed for the work unit and meet other specified criteria for the work unit, INQUIRY 204. Input to this decision is resource information 203, including, for instance, CPU times, region sizes, programs, files, etc. A work unit may be ineligible to offload if, for instance:
If the criteria cannot be met, then in this example, the work unit is not scheduled for offload processing, STEP 206, and standard processing is continued, STEP 216. For example, the work unit is scheduled to execute on the main processor. In a further example, if the criteria cannot be met, a determination is made as to whether the work unit is prepared to wait for an offload processing system that can meet the criteria or for the criteria to change (e.g., program or work unit now defined to be eligible for offloading). If so, INQUIRY 204 is repeated after a defined delay. Otherwise, standard processing is performed, in which the work unit is scheduled to execute on the main processor.
Returning to INQUIRY 204, if there are one or more offload processing systems that meet the specified criteria, then a determination is made as to whether one or more of those offload processing systems have the required resources currently available for executing the work unit, INQUIRY 208. If not, then, in one example, a determination is made as to whether the work unit is prepared to wait for an offload processing system, STEP 210. If the work unit is not prepared to wait, then the work unit is not scheduled for offload, STEP 206, and processing continues with STEP 216, in which in this example, the work unit is scheduled to execute on the main processor. Otherwise, INQUIRY 208 is repeated after a defined delay. In one example, it may be repeated a number of times depending on policy.
Returning to INQUIRY 208, if there are one or more offload processing systems that meet the criteria and currently have available resources (including hardware, software and/or external attachment resources), then one of the offload processing systems is selected for executing the work unit, STEP 212. If there are more than one offload processing systems available that have the required resources, then a technique is used to select one of the processing systems. For example, a round robin approach may be used or a priority may be assigned to each offload processing system and the selection is based on priority. Many other techniques are also available. In one particular example, a best fit technique is used in which the offload processing system that best fits the work unit based on a defined formula is selected. One specific example of this is provided below.
This specific example is intended to define what resources and services are required to validate that a particular work unit can be offloaded and to which specific offload processing system (OFL). The work unit requirements together with the available resources in one or more OFLs, when merged, determine whether a work unit can run and where. One specific assumption in this example is that only one OFL is used in servicing a work unit. (In other examples, this assumption is not made.)
A work unit employs certain services and offload processing systems provide a (possibly asymmetric) set of services. Matching these in the most cost effective way is a goal, in this example. There are other potential services or requirements that are imposed by customers—for example, a job is to run within a specific time window—that are not included in this example, but may be included in others. The data included here is from job control information (e.g., JCL)—i.e., I/O profile, the invoked program's characteristics and known features of the system it runs on.
Table 1 below shows examples of scheduling resources, whether they are singular or multiple, offload processing systems (OFLs) matching the resources and relevant comments and constraints.
There may be a simple rule describing what to do if a processing system does or does not have the equivalent resource; or there may be more complex rules governing them. Also, the importance of some rules is higher than others, and lastly some offload resources are more valuable so need to be scheduled with that in mind; that is, in an order of preference. Examples are depicted in Table 2.
Table 2 describes rules for examples that may be used:
Decision Making Process:
In this example, there is an implied order in resource matching, from the most restrictive (or most expensive) to the least. It is ‘possible’ that there could be an override to this. The idea is to strike out OFLs that cannot meet the requirements so that the OFL with the least available resources meeting the complete request is chosen. If there are none, the work unit is not offloadable. The implied order for resource allocation is, in one example:
With the Above:
Continuing with STEP 212 of
Thereafter, standard processing continues, STEP 216, which in this case includes assigning the work unit to execute on the selected offload processing system.
Some time after the work unit is assigned for execution (e.g., seconds, minutes, hours, days, etc.), execution of the work unit is initiated and certain processing is performed, as described with reference to
The resource data (e.g., the list of known resources required to execute this work unit) is obtained by the step analyzer (or another analyzer in another example) and sent to the selected offload processing system, STEP 300. In one example, the resource data is sent to the offload processing system via an offload support agent which interfaces with the offload processing system, STEP 302. A work unit marked as eligible for offloading has its original name and requested region size saved and replaced by the name and region requirements of the offload support agent. In one example, these changes are made without altering the JCL listing.
The offload support agent validates that the work unit can still be offloaded, captures work unit information (e.g., the list of required resources), and forwards the package to the offload processing system. The offload support agent executes on the main processor complex and provides access to services on the main system (e.g., only on the main system), such as spooling services and local DASD. The offload support agent is a problem state program executing on the main processor with no special privileges. It analyzes the resources needed for the work unit, requests an offload processing system based on this and passes the resource data to the offload processing system. It then processes service requests from the running work unit using, for instance, local resources 307. For instance, in a mainframe environment having a main processor (e.g., mainframe processor) and offload processing system, the work unit may be executed on an offload processing system, but certain mainframe services are desired as part of the execution. These services are requested by the offload processing system and performed by the offload support agent that has access to the resources (307) needed for the service.
In one example, the offload support agent:
Responsive to the offload support agent providing the work unit and related information to the offload processing system, the offload processing system obtains the resource list (e.g., the list obtained in STEP 300), fetches the requested program 301, and begins its execution, STEP 304. It has access to shared resources 309 on the main system (e.g., an IBM® system), as well as offload server resources 311.
The offload processing system processes the work unit as it would any other work unit, including performing its own internal (i.e., operating system) scheduling, etc. It returns a result and/or condition code to the offload support agent, which provides this information to the main processor.
Described above is a system-wide, generic technique, integrated with the operating system, for offloading work units to offload processing systems. The technique encompasses, for instance, all jobs and work units that are run by the operating system. In one example, in which the operating system is z/OS®, the technique includes offloading DB/2®, CICS®, batch, TSO and other work units, based on their specific resource requirements. Manual scheduling is not needed, and neither is management by subsystems, like DB/2® and CICS®. DB/2® and CICS® are registered trademarks of International Business Machines Corporation, Armonk, N.Y.
In an environment with asymmetric multiple processors containing an asymmetric set of hardware and/or software, in one aspect of the present invention, a determination is made as to which is the best processing system to use to execute a specific work unit. A technique is provided for obtaining the resource requirements of a work unit and maintaining a current list of available offload processing systems with their available resources. It then computes the best fit offload processing system to use for this work unit, based on general and specific inputs, or rejects the work unit as an offload candidate, thus executing it on the main system.
In one example, the job control language statements for each work unit is evaluated for: specific exclusion/inclusion in offload evaluation; resource requests that prohibit offloading a work unit; resource requests that target a set of or individual offload processing systems; and/or programs or files that prohibit offload due to license or other constraints. If all the criteria for offload are met, then, in one example, when a work unit is scheduled for execution, a determination is made as to whether an eligible offload processing system is available. If so, it is sent to the offload processing system for execution. Otherwise, the work unit is either re-queued for processing on the main processor or it waits for an offload processing system.
This general technique for analyzing the execution requirements of work units, matching those requirements to resources of specific function or specialized processors, then once matched, offloading work to these processing systems, obtains multiple economies, including, for instance:
By offloading these work units, it is also possible to decrease license costs by:
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, 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, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus or device.
A computer readable storage medium may be, for example, but 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 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
Program code embodied on a computer readable medium may be transmitted using an appropriate medium, including, but not limited to, wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for 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 latter scenario, 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).
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 the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of 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 that 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 be provided, offered, deployed, managed, serviced, etc. by a service provider who offers management of customer environments. For instance, the service provider can create, maintain, support, etc. computer 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 receive payment from the customer under a subscription and/or fee agreement, as examples. Additionally or alternatively, the service provider may receive 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, the deploying of an application comprises providing computer infrastructure operable to perform one or more aspects of the present invention.
As a further aspect of the present invention, a computing infrastructure may be deployed comprising integrating computer readable code into a computing system, in which the code in combination with the computing system is capable of performing one or more aspects of the present invention.
As yet a further aspect of the present invention, a process for integrating computing infrastructure comprising integrating computer readable code into a computer system may be provided. The computer system comprises a computer readable medium, in which the computer medium comprises one or more aspects of the present invention. The code in combination with the computer system is capable of performing one or more aspects of the present invention.
Although various embodiments are described above, these are only examples. For example, computing environments of other architectures can incorporate and use one more aspects of the present invention. Additionally, other types of offload processing systems or offload support agents may be used. Further, other criteria, tests and/or rules may be used to determine if a particular work unit is to be offloaded, and if so, to which offload processing system.
Further, other types of computing environments can benefit from one or more aspects of the present invention. As an example, an environment may include an emulator (e.g., software or other emulation mechanisms), in which a particular architecture (including, for instance, instruction execution, architected functions, such as address translation, and architected registers) or a subset thereof is emulated (e.g., on a native computer system having a processor and memory). In such an environment, one or more emulation functions of the emulator can implement one or more aspects of the present invention, even though a computer executing the emulator may have a different architecture than the capabilities being emulated. As one example, in emulation mode, the specific instruction or operation being emulated is decoded, and an appropriate emulation function is built to implement the individual instruction or operation.
In an emulation environment, a host computer includes, for instance, a memory to store instructions and data; an instruction fetch unit to fetch instructions from memory and to optionally, provide local buffering for the fetched instruction; an instruction decode unit to receive the fetched instructions and to determine the type of instructions that have been fetched; and an instruction execution unit to execute the instructions. Execution may include loading data into a register from memory; storing data back to memory from a register; or performing some type of arithmetic or logical operation, as determined by the decode unit. In one example, each unit is implemented in software. For instance, the operations being performed by the units are implemented as one or more subroutines within emulator software.
Further, a data processing system suitable for storing and/or executing program code is usable that includes at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements include, for instance, local memory employed during actual execution of the program code, bulk storage, and cache memory which provide temporary storage of at least some program code in order to reduce the number of times 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, tape, CDs, DVDs, thumb drives 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 modems, and Ethernet cards are just a few of the available types of network adapters.
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, if any, 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 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 embodiment with various modifications as are suited to the particular use contemplated.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4394727 | Hoffman et al. | Jul 1983 | A |
| 5126932 | Wolfson et al. | Jun 1992 | A |
| 5301324 | Dewey et al. | Apr 1994 | A |
| 5303369 | Borcherding et al. | Apr 1994 | A |
| 5437032 | Wolf et al. | Jul 1995 | A |
| 5701482 | Harrison et al. | Dec 1997 | A |
| 5748468 | Notenboom et al. | May 1998 | A |
| 5793982 | Shrader et al. | Aug 1998 | A |
| 5881238 | Aman et al. | Mar 1999 | A |
| 6085217 | Ault et al. | Jul 2000 | A |
| 6370599 | Anand et al. | Apr 2002 | B1 |
| 6496823 | Blank et al. | Dec 2002 | B2 |
| 6591262 | MacLellan et al. | Jul 2003 | B1 |
| 6742006 | Raduchel et al. | May 2004 | B2 |
| 6898673 | Gruner et al. | May 2005 | B2 |
| 6901488 | Gruner et al. | May 2005 | B2 |
| 6901583 | Park | May 2005 | B1 |
| 7941647 | Yates et al. | May 2011 | B2 |
| 8127121 | Yates et al. | Feb 2012 | B2 |
| 20040187126 | Yoshimura | Sep 2004 | A1 |
| 20070226745 | Haas et al. | Sep 2007 | A1 |
| 20070283349 | Creamer et al. | Dec 2007 | A1 |
| 20080098208 | Reid et al. | Apr 2008 | A1 |
| 20080189714 | Ault et al. | Aug 2008 | A1 |
| 20080216073 | Yates et al. | Sep 2008 | A1 |
| 20090012981 | Kogoh | Jan 2009 | A1 |
| 20090089794 | Hilton | Apr 2009 | A1 |
| 20090313633 | Nardelli et al. | Dec 2009 | A1 |
| 20110289519 | Frost | Nov 2011 | A1 |
| 20120144167 | Yates et al. | Jun 2012 | A1 |
| 20120192191 | Jellinek et al. | Jul 2012 | A1 |
| 20120222033 | Byrum et al. | Aug 2012 | A1 |
| Number | Date | Country |
|---|---|---|
| WO0161470 | Aug 2001 | WO |
| Entry |
|---|
| Huerta-Canepa, G. Dongman Lee, “An Adaptable Application Offloading Scheme Based on Application Behavior,” 22nd International Conference on Advanced Information Networking and Applications, Mar. 25-28, 2008, pp. 387-392 (Abstract Only). |
| Putnikovic, Branimir, Soran Skocir, “Database Migration Using Standard Data Unload and Load Procedures on z/OS Platform,” 9th International Conference on Telecommunications, Jun. 13-15, 2007, pp. 259-266. |
| Office Action for U.S. Appl. No. 13/034,775 dated Nov. 8, 2012. |
| “z/Architecture—Principles of Operation,” IBM Publication No. SA22-7832-08, 9th Edition, Aug. 2010, pp. 1-1496. |
| Number | Date | Country | |
|---|---|---|---|
| 20120192191 A1 | Jul 2012 | US |
