Patent Application
20070143738
The present invention relates generally to logical partitioning of computer systems and, more particularly, to a method for efficient utilization of processors in a virtual shared environment.
In a single physical computer system having multiple physical processors with logical resource partitioning capabilities (e.g., U.S. Pat. No. 4,843,541), it is possible to have two or more operating systems (OSs) simultaneously executing on the physical processors. Two higher-level configurations generally exist when defining the use of the available processors by the logical partitions: dedicated or shared. A partition that makes use of dedicated processors signifies that physical processors are dedicated to a particular partition. In other words, a dedicated physical processor handles the processing for one specific logical partition.
On the other hand, a partition that makes use of shared processors means that the physical processors can be assigned in partial processor increments to particular partitions. An example of such a shared partition configuration 200 is shown in
In either the dedicated or shared configurations, a partition can define both a minimum number of processors (and partial processors for the shared case) and a maximum number of processors, such that the sum of each of the minimum values (including partial processor increments) of each of the partitions defined cannot exceed the number of actual physical processors. For example, in the dedicated configuration of
With regard to the shared configuration of
In both
When operating in a shared environment such as shown in
To address this concern, certain OS instances attempt to utilize the exposed system services to relinquish a processor when a low utilization (of processing capability) is detected, and also attempt to acquire a processor when a low-to-high utilization transition is detected. The specific internals of a particular OS will dictate how the low utilization and low-to-high utilization transitions are detected, the mechanics of which are not discussed in further detail hereinafter. One of the more common methods for selecting a particular processor to acquire is to simply select all of the system processors and attempt to acquire each one of them, as opposed to selecting a single specific processor. However, in certain instances, this can actually be a less efficient approach as compared to relying solely on the hypervisor to manage the processor resources, due to the increased use of the hypervisor by the requesting OS. Furthermore, this blanket approach could also result in several of the acquired processors becoming active with no application workload to process, as other previously acquired processors have already begun to process the workload.
Another possibility is to maintain a list of available processors and use a round-robin approach to select the next processor to acquire whenever a low-to-high utilization transition is detected. Although this approach represents somewhat of an improvement over the first approach of attempting to acquire all available processors, it is still not ideal since a rudimentary round-robin search may attempt to acquire a processor that provides a unique functionality with respect to available processors, and would thus not be an appropriate choice for acquisition.
Accordingly, it would be desirable to be able to more efficiently select a processor following a low-to-high transition a in a virtual, shared processing environment.
The above discussed drawbacks and deficiencies of the prior art are overcome or alleviated by a method for selecting a processor to be acquired in a virtual, shared computing environment. In an exemplary embodiment, the method includes initiating a first selection phase to attempt to acquire a last relinquished processor of the shared computing environment, and initiating a second selection phase in the event of a failure of the first selection phase in acquiring the last relinquished processor. The second selection phase further includes a round-robin selection process for presently relinquished processors.
In another embodiment, a storage medium includes a machine readable computer program code for selecting a processor to be acquired in a virtual, shared computing environment, and instructions for causing a computer to implement a method. The method further includes initiating a first selection phase to attempt to acquire a last relinquished processor of the shared computing environment, and initiating a second selection phase in the event of a failure of the first selection phase in acquiring the last relinquished processor, the second selection phase further including a round-robin selection process for presently relinquished processors.
Referring to the exemplary drawings wherein like elements are numbered alike in the several Figures:
Disclosed herein is a method for the efficient selection of a processor to acquire in a virtual, shared environment. Generally stated, the methodology utilizes a two-phase selection process, the first phase of which seeks to reuse or acquire the last relinquished processor (i.e., the most recently relinquished processor). In selecting the last relinquished processor to acquire, there exists the highest likelihood of retrieving the cache of the acquired processor that contains data still valid with respect to the requesting OS. Where each of the OS instances present in a shared environment first attempts to acquire its last relinquished process, a decreased utilization of the entire computer system will result due to a combination of decreased hypervisor overhead and positive cache effects. This decrease in hypervisor utilization will in turn allow for an increased capacity to process the application workload.
In the event that the identification of the last relinquished processor is not defined or is no longer available (as will be described in further detail hereinafter), a second selection phase may then be implemented. This second phase includes the selection of a processor in an improved, extensible round-robin fashion that is based largely on the specific requirements of the implementing OS. By selecting a processor according to such a two-phase methodology (as opposed to selecting and attempting to acquire all processors, or through a simple, non-extensible round-robin fashion), a decrease in overall utilization of the computer system will be achieved.
It should be understood at this point that the exemplary method embodiments disclosed herein are directed toward efficient selection and utilization (by the hosted operating systems) of the processors in a computer system that includes logical shared partitioning of particular resources, and are not specifically concerned with the particular mechanisms that could be used to detect both the low utilization and low-to-high utilization transition conditions. In other words, the present selection methodology may be used in conjunction with any number of acceptable ways in the art for defining and distinguishing between low utilization states (of processing resources), high utilization states and the transitions therebetween.
In the exemplary embodiments presented herein, various variables and services are defined as references for the disclosed selection methodology. These references include, for example, the processor shared variables “last_relinquished” and “last_acquired”. The last_relinquished variable for a given OS stores an identifier of the last processor that relinquished itself to the hypervisor, and can have as possible values: [NULL, 1,2,3, . . . n] where n is the total number of processors available for use by the logical partition in which the particular OS instance is operating. Similarly, the last_acquired variable for a given OS stores an identifier of the last processor that was acquired via the selection method described hereinafter. It can have as possible values [NULL, 1,2,3, . . . n] where n is the number of processors available for use by the logical partition in which the particular OS instance is operating. The relinquished_list variable is also used for each processor that identifies whether that particular processor has been relinquished. For example, the designation relinquished_list[3]=1 can signify that processor number 3 has been relinquished.
In addition, exemplary hypervisor services include “Acquire [n]” and “Relinquish [n]”. The Acquire [n] service takes as input [n] the identifier of the processor that is requested to resume processing on behalf of the invoking OS instance, while the Relinquish [n] service takes as input [n] the identifier of the processor that is to be relinquished to the hypervisor on behalf of the invoking OS instance.
Prior to the detailed illustration of the present two-phase selection process,
Then, as shown at block 304, the variable “relinquish_list” for the released processor is set to a logical true condition to indicate that such processor is now on a list of relinquished processors, as shown at block 304. It will be noted that, depending upon the particular operating system, certain processors may be excluded from the selection process by not allowing those processors to be included within the list of acceptable values for last_relinquished, and by not allowing them to be included on the relinquished list (e.g., where processor “x” is to be excluded from the selection process, the value “x” is not valid for the variable last_relinquished, and relinquished_list[x]=0 in all cases). This can be considered to be an extensibility feature of the selection process. However, assuming the processor in the OS may be relinquished, after setting the last_relinquished and relinquished_list variables, the OS invokes a relinquish request to the hypervisor for that processor, as shown in block 306.
Referring generally now to
On the other hand, assuming the value of last_relinquished is not NULL following a detected low-to-high utilization, the first phase then proceeds to block 406 where the variable last_acquired is set to the current (non-NULL) value of last_relinquished. Then, in block 408, the variable last_relinquished is then set to NULL. Thus, once the first phase attempts to acquire the last relinquished processor, then that processor is no longer considered to be the last relinquished processor regardless of whether the hypervisor ultimately grants the acquire request. As then shown at block 410, the OS invokes an acquire request to the hypervisor for that processor. Since the first phase was successfully run in this example (i.e., the last relinquished processor was identified and requested), the second phase is not entered in this iteration of the process.
Because the processor-shared variable last_relinquished is set to NULL in block 408, it is therefore possible that this value could still be NULL the next time a low-to-high utilization is detected. That is, upon the next detection of a low-to-high utilization, no intervening high-to-low utilization has been detected (
The last_relinquished variable may be considered to be a one-deep queue. Immediately prior to issuing a Relinquish [ ] request for a processor that has detected a low utilization situation, the identifier of the processor to be relinquished is stored (using block-concurrent operations) in the last_relinquished variable, as will be recalled from
Referring now to the flow diagram 500 of
In the present embodiment, the second phase begins at decision block 502 to check whether the current location of the last acquired processor is at the end of the processor list. In order for proper operation of the extensible round-robin phase, block-concurrent operations are used to keep track of the current location. Thus if last_acquired+1 is greater than the total number of processors, then this variable is at the end of the list, and the value of last_acquired is then reset to zero, as shown at block 504. An extensible aspect of the second phase is that, depending upon the particular characteristics of the OS, the resetting of the last_acquired variable may be tailored to be biased to a particular processor (instead of the first on the list). For example, an embodiment of the round-robin phase can exclude the first processor from the round-robin when the system is not a true SMP (i.e., certain system functions must be performed on a specific processor). In addition, other embodiments may reset the current round-robin position to the nominal starting round-robin position whenever the first phase was successful at selecting the last relinquished processor to acquire. Further, the round-robin processing may also be exited and restarted based on certain defined system events.
If the current round-robin position is not at the end of the list, then the last_acquired value is instead incremented by one as shown in block 506, and the phase proceeds to decision block 508 to determine if the current block identified by the round-robin is in fact on the relinquished list. That is, block 508 checks to see whether the value of relinquished_list for the particular processor currently designated by the last_acquired variable is equal to zero. This would signify that this processor is currently not on the relinquished list. If this is the case, then the round-robin phase returns back to block 502 for further resetting and/or incrementing of last_acquired. Still another extensible aspect of this phase is that certain processors can be effectively excluded from the relinquished list by permanently designating the relinquished_list variable for that processor to be equal to zero. Finally, if it is determined that the processor identified by the current value of last_acquired is on the relinquished list, the relinquished_list variable for that processor will be set to zero at block 510 (effectively removing it from the relinquished list), and the second phase then proceeds to block 512, where the OS invokes an acquire request to the hypervisor for that processor.
In view of the above, the present method embodiments may therefore take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits. A technical effect of the executable instructions is to implement the exemplary method described above and illustrated in
While the invention has been described with reference to a preferred embodiment or embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out this invention, but that the invention will include all embodiments falling within the scope of the appended claims.
