Method and apparatus for controlling available processor capacity5835767Abstract A method and system are disclosed for limiting the processing power of a CPU or CPUs in a multi-processing system comprising at least one constrained or hobbled CPU and a main memory. The novel method includes executing a high priority process on the CPU which effectively interrupts the processing of a task at a predetermined time T.sub.1 during a full time cycle T.sub.0 -T.sub.2 rendering the CPU unavailable for a predetermined period of time (T.sub.1 to T.sub.2) which represents a predetermined percentage of the CPUs full computing power. The task that is interrupted is continued at the start of the next time cycle of the CPU so that all tasks are completed. The power of any CPU so hobbled may be decreased by a predetermined percentage of full power by decreasing the processing time cycle between T.sub.0 and T.sub.1, without the need for hardware or operating system modification. Claims What is claimed: Description FIELD OF THE INVENTION
__________________________________________________________________________
IF NOT CPUHOBBLED (EMODE.sub.-- MACHINEINFO2, HOBBLE.sub.-- FACTOR)
THEN
<Regular Process>
ELSE
<"Soaker" Process>
__________________________________________________________________________
As shown below, several initialization calculations are performed in preparation for executing the second branch of the answering service process. 1. CPUHOBBLED determines if the CPU is a reduced capacity processor via EMODE.sub.-- MACHINEINFO2 and if so, returns available capacity, as a percentage, in HOBBLE.sub.-- FACTOR. This is converted to the ratio of the complete cycle interval and the available interval which simplifies the other calculations. HOBBLE.sub.-- FACTOR:=100/MAX(HOBBLE.sub.-- FACTOR,1); 2. The end of the first available interval (T1) is calculated as CLOCK+5 SECONDS and stored in AVAIL.sub.-- END. A long first available interval allows full processor capacity during early initialization or just after the processor has been acquired into the partition. 3. The end of the first unavailable interval (T2), which is also the end of the first cycle, is made the same as the end of the first available interval and is stored in CYCLE.sub.-- END. After the above initialization calculations, the "soaker" aspect can now function. Referring back to normal operation, the first branch of the answering service process, represented below, is a loop which responds to memory dump requests and IPC requests.
______________________________________
WHILE BOOLEAN (MYUSAGE.WRONGNUMBER) DO
BEGIN
WAITANDRESET (LISTEN.sub.-- EVENT›CPMNO!);
CHECKANDHANDLEDUMPS;
LISTEN;
END;
______________________________________
This loop continues to use the full capacity of enabled processors. The answering service process, once started, waits (via a WAITANDRESET) on a LISTEN.sub.-- EVENT of its respective processor. When awakened, ANSWERINGSERVICE first checks to see if the processor is needed for a memory dump. ANSWERINGSERVICE next calls the LISTEN procedure to handle inter-processor communication. ANSWERINGSERVICE loops by doing the wait, the memory dump check, and the call on LISTEN until it is informed that its processor is no longer in the partition. This general implementation of ANSWERINGSERVICE is referred to as the first branch of the answering service process. The processor time consumed by this process is accumulated in a system wide account "listen" (LISTENCLOCKX). As mentioned, in the exemplary embodiment of the present invention, a second branch of the answering service process has been developed to control processors that are designated to run at a reduced capacity. The second branch has two major functions. First, it performs the same functions as the first branch of the answering service process of answering memory dump requests and inter-processor communication (IPC) requests. Second, it has the added responsibility of providing reduced capacity by making a specified percentage of processor time unavailable to other processes. Although, it should be noted that, in the exemplary embodiment of the present invention, even while the processor is so-called "unavailable", memory dump and IPC requests are responded to as described below. In general, the method employed by the second branch of the answering service process for limiting processor capacity is to alternately make the processor available for processing and not available for processing as illustrated in FIG. 1. In the exemplary embodiment of the present invention, this technique is applied on a per processor basis. Therefore, in a multiple processor environment, all processors can be operating with different effective capacities. FIG. 3 is a flowchart illustrating a high level flow for the capacity control process illustrated in the time line of FIG. 1. As shown, at step 310, times T1 and T2 are calculated and the processor is marked as available. At step 312, the process waits until T1 then marks the processor as unavailable at step 314. When the processor is marked as unavailable, it executes a set of predetermined instructions to waste time, step 316. Finally, at step 318, the time is checked: if it is T2, the the process loops back to step 310, otherwise the process loops back to step 316 to waste more time. By definition, processor time spent performing answering service functions (IPCs and memory dumps) is considered available time. However, in the exemplary embodiment of the present invention, requests to perform answering service functions can occur at any time. That is to say, a request can start or end during what otherwise would be unavailable time. For example, when the processor time needed for inter-processor communication over extended periods of time exceeds the time available on a reduced capacity processor, inter-processor communication receives all the time that it needs. On balance, in the exemplary embodiment, it was determined that it is better to delay the enforcement of capacity reduction rather than delay inter-processor communication. In the exemplary embodiment, processor time spent performing answering service functions during what should be unavailable time is borrowed from the next available interval. This is done, for example, by extending the end point (time T2) of the current unavailable interval and shortening the next available interval by the same amount. To handle this situation, special case handling of this type of situation is built into the second branch of the answering service process. FIG. 4 shows the flowchart of FIG. 3 modified to include the special case where available time is borrowed from subsequent intervals. As shown in FIG. 4, after step 310, the process waits for either T1 (like step 312 of FIG. 3) or an answering service request, step 410. If there is an answering service request, step 412, then the process performs the request and calculates the available time error, steps 414 and 416. After performing the request, the process branches back to step 410. The available time error shown in FIG. 4 is the amount of time beyond time T1 spent performing an answering service function. The unavailable error in FIG. 4 is the amount of time during an unavailable interval (the time before time T2) spent performing an answering service function. The next available interval is shortened by the sum of the available time error and the unavailable time error. The general outline of the second branch of the answering service process is represented below:
______________________________________
WHILE BOOLEAN (MYUSAGE.WRONGNUMBER) DO
IF WAITANDRESET (((AVAIL.sub.-- END - CLOCK)/ONESECOND),
LISTEN.sub.-- EVENT›CPMNO!) EQL 1 THEN
BEGIN % TIME WAKE UP
<Unavailable time process>
END
ELSE
BEGIN % EVENT WAKE UP
<IPC or Memory dump during available time>
END
______________________________________
As seen, the second branch also has branches which allow the process to wake up on time or to wake up on an event. In the exemplary embodiment, the TCP 214 wakes up the answering service process and informs it whether the wake up is due to time or an event. The WAITANDRESET portion is essentially the available time period. The wake up on time is essentially the unavailable time period where the wake up on event is, for example, an IPC request during an available time period. When this branch wakes up on an event, checks for a memory dump and/or IPC requests are made. There are also some additional steps. In the exemplary embodiment of the present invention, because ANSWERINGSERVICE initially sets a utilization class to LISTENCLOCKX, one of the first steps performed by the second branch is to change the utilization class to BLACKHOLECLOCKX and the last thing it does is change the utilization class back to LISTENCLOCKX. It should be noted that the utilization class, however, is changed to LISTENCLOCKX for the IPC request processing and then back to BLACKHOLECLOCKX. As described above with reference to FIG. 4, answering service requests may occur or extend into an otherwise unavailable time period. For example, if an IPC request extends into an unavailable interval, the amount of the intrusion is calculated and stored in AVAIL.sub.-- ERR. The store of CLOCK into CLK establishes the end of the IPC period (Ty). An exemplary psuedo-code for the wake up on event branch is shown below.
______________________________________
BEGIN % EVENT WAKE UP
CHECKANDHANDLEDUMPS;
AVAIL.sub.-- ERR:=-MAX (AVAIL.sub.-- END, CLOCK);
SET.sub.-- TCP.sub.-- CLASS (SNR, PIB, LISTENCLOCKX, 0);
LISTEN;
SET.sub.-- TCP.sub.-- CLASS (SNR, PIB, BLACKHOLECLOCKX, 0);
AVAIL.sub.-- ERR:=*+MAX (AVAIL.sub.-- END, CLK);
END
______________________________________
Waking up on time, signals the end of an available interval and the start of an unavailable interval (e.g., T1). The unavailable time process has three parts. 1. Initialization involves any needed adjustment to the end of the unavailable interval (T2). The adjustment is the result of intrusion into the unavailable interval by the preceding available interval. The adjustment is limited to a maximum value of the length of an available interval. 2. The process loops checking for the end of the unavailable interval, a memory dump request, and an IPC request. The time consumed by IPC that occurs before the original end of the unavailable interval will extend the unavailable interval. This time is borrowed from the next available interval. 3. The end of the unavailable interval is the end of a cycle. New values for the length of an available interval, the end of the next available interval, and the end of the next unavailable interval are calculated. An exemplary psuedo-code for the wake up on time branch is shown below.
__________________________________________________________________________
BEGIN % TIME WAKE UP
CLK:=CLOCK;
IF AVAIL.sub.-- ERR EOL 0 THEN
CYCLE.sub.-- END:=*+MAX(MIN((CLK-
AVAIL.sub.-- END) ,NOMINAL.sub.-- AVAIL) ,0);
AVAIL.sub.-- ERR:=MIN (AVAIL.sub.-- ERR, NOMINAL.sub.-- AVAIL);
CYCLE.sub.-- END:=*+AVAIL.sub.-- ERR;
WHILE CLK LSS CYCLE.sub.-- END + LISTEN.sub.-- ERR DO
BEGIN
THRU 600 DO
BEGIN
PURGE.sub.-- ACAM;
CHECKANDHANDLEDUMPS;
IF COMWORD›CPMNO! ISNT 0 THEN
BEGIN
LISTEN.sub.-- ERR:=-MIN (CLOCK, CYCLE.sub.-- END);
SET.sub.-- TCP.sub.-- CLASS (SNR, PIB, LISTENCLOCKX, 0);
LISTEN;
SET.sub.-- TCP.sub.-- CLASS (SNR, PIB, BLACKHOLECLOCKX, 0);
LISTEN.sub.-- ERR:=*+MIN (CLOCK, CYCLE.sub.-- END);
END;
END;
CLK:=CLOCK;
END;
NOMINAL.sub.-- AVAIL:=ONESECOND DIV SBPSLICERATE;
AVAIL.sub.-- END:=MIN ((CLK-(CYCLE.sub.-- END+LISTEN.sub.-- ERR)),
NOMINAL.sub.-- AVAIL)+NOMINAL.sub.-- AVAIL - AVAIL.sub.-- ERR
- LISTEN.sub.-- ERR;
CYCLE.sub.-- END:=CLK + NOMINAL.sub.-- AVAIL * HOBBLE.sub.-- FACTOR;
AVAIL.sub.-- ERR:=0;
LISTEN.sub.-- ERR:=0;
AVAIL.sub.-- END:=AVAIL.sub.-- END + CLOCK;
END
__________________________________________________________________________
Several statements in the code are described below. 1. The "THRU 600 DO" reduces the frequency of clock fetches which are messages to the input/output module (IOM). The value 600 was obtained experimentally. Larger values cause the reduced capacity to be greater than the specified percentage. 2. The "PURGE.sub.-- ACAM" purges an associative memory (not shown) used in the exemplary embodiment of the CPU. As described above, the technique used for reducing capacity is to alternately make the processor available for use by other processes and then make the processor unavailable. Referring to FIGS. 5-11 examples illustrating possible scenarios are described. The time line of FIG. 5 shows an IPC occurring entirely during available time. The interval T0 to T1 is considered available time. Point T1 does not change just because part of the available time was used for IPC. At point T0, a "soaker" process waits on both time and its processor's listen event with the time value being the difference between T1 and T0. At point Tx, the "soaker" process wakes up on the listen event and checks for a memory dump request and for an IPC request. At point Ty, all requests have been completed so the soaker process returns and continues to wait on time and listen event. The time value for this wait period is the difference between T1 and Ty. The following examples require consideration of more than one cycle. The time line of FIG. 6 shows two complete cycles. The intervals T0 to T1 and T2 to T3 are available time. The intervals T1 to T2 and T3 to T4 are unavailable time. As shown in FIG. 7, if an IPC request occurs during an unavailable period, the unavailable period is suspended and restarted after the IPC completes. The IPC time is considered available time which is borrowed from the next available interval. If, as shown in FIG. 8, the IPC starts during an unavailable interval but ends after the unavailable interval would have ended, only the time from when IPC starts until when the unavailable interval would have ended is borrowed. In this case, as shown in FIG. 8, point T2 is shifted to the right on the time line but never goes beyond point T3. In the exemplary embodiment of the present invention, memory dump requests do not borrow from the next available time interval. If a memory dump request starts during an unavailable interval and completes before time T2, the unavailable period continues. If, however, as shown in FIG. 9, the memory dump request completes after time T2, points T2 and T3 are shifted to the right such that T2 coincides with the completion of the dump. As shown in FIG. 10, an IPC request which starts during an available interval at time Tx, continues until time Ty. As seen, time Ty is after what should have been the end of the available interval. The unavailable interval starts when the IPC request ends and extends into what should have been the start of the next available interval. The amount borrowed from the T2 to T3 available interval is equivalent to the amount added to the T0 to T1 available interval. As shown in FIG. 11, a memory dump request starts during an available interval and effectively ends the available interval. At the completion of the memory dump, the next unavailable interval starts. Time is not borrowed from the available interval T2 to T3. It should be noted that, in the above examples, the description of each scenario is examined in isolation. In practice, however, multiple IPC requests are generally handled during each complete cycle. It should also be noted that cycle time (i.e., available time versus unavailable time) has a direct impact on system performance. If the cycle time is too long, an interactive application might exhibit very choppy response times. If the cycle time is too short, the overhead of stack switching for CPUs 210 can become significant since a process switch occurs at points T0, T1 and T2. In addition to cycle time, slice rate can have a similar impact on system performance as the cycle time. TCP 214, in the exemplary embodiment, switches between tasks of equal priority based on the slice rate. Presently, the slice rate is limited to the range of 10 to 200 slices per second with a default of 60. The available time will be the same as the slice time, which will fall in the range of 5 to 100 milliseconds. In the exemplary embodiment of the present invention, processor time is accounted for. For the regular answering service process, processor time is accumulated in a "listen" utilization account. For, the "soaker" process, processor time is accumulated in a "reduce capacity" utilization class. In the exemplary embodiment, the accounting for processor utilization by class is done by the TCP 214. It should be noted that, to accurately track how much time a processor is available, the soaker process changes the utilization class to "listen" before calling LISTEN and changes the utilization class back to "reduce capacity" after returning from LISTEN. Processor resource utilization can be reported in many ways. It can be reported through an operator interface. It can also be retrieved programmatically through operating system interfaces (e.g., GETSTATUS and SYSTEMSTATUS). It should be noted that, in the exemplary embodiment of the present invention, each processor in the system of FIG. 2 has associated with it a style PROM on a state access module (SAM) card (not shown). Among the many items contained in the style PROM is an indicator that designates the associated processor as full capacity or reduced capacity. When the processor is initialized, the capacity indicator is moved into a processor identification state which is accessed when the determination is needed. The present invention, in its exemplary form, although employed on the Unisys A series computer systems (e.g., A19 series), has applicability to many other computer systems. Although illustrated and described herein with reference to certain specific embodiments, the present invention is nevertheless not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the spirit of the invention.
|
Same subclass Same class Consider this |
||||||||||