Scheduling of time critical processes

Scheduling of time critical processes by OMRI SERLIN SYSTEMS Engineering Laboratories Fort Lauderdale, Florida INTRODUCTION allocation policies that...
Author: Jemima Fisher
1 downloads 2 Views 761KB Size
Scheduling of time critical processes by OMRI SERLIN SYSTEMS Engineering Laboratories Fort Lauderdale, Florida

INTRODUCTION

allocation policies that satisfy the requirements of multiple time-critical processes (TCPs) .'These processes, arising naturally in real-time environments, are computational procedures bound by hard deadlines. A process bound by a deadline must, once initiated, complete its computation on or before the specified deadline. A hard deadline implies that a failure to meet it results in an irreparable damage to the computation. Such deadlines are typically due to stability and accuracy considerations in the process being controlled (e.g., the analog computation portion of a hybrid system). An efficient CPU allocation algorithm is one that guarantees to each TCP sufficient processor time to complete its task before its deadline, while minimizing forced idle CPU time. By "forced idle time" is meant the time during which the CPU must remain idle in order to accommodate the occasional worst-case condition. This constraint is essential if the problem is to be non-trivial. A basic assumption underlying this study is that all TCPs are preemptible. Time-critical processes are most commonly initiated by the occurrence of external events (interrupt signals). Time-of-day or elapsed-time prompting of these processes may be regarded as special cases of the general class of external events. These events, and the associated TCPs, may be further classified as periodic or asynchronous. The TCPs to be serviced are assumed to form an unordered set, that is, they are not interrelated by precedence rules. This assumption is consistent with the premise that the TCPs are initiated by unrelated external signals. If a TCP calls on other tasks, then such secondary tasks can be regarded simply as chronological extensions of the calling TCP, either because the called task is private to the calling TCP, or because all shared tasks are reentrant. In fact, the concept of precedence rules is relevant only in the case of scheduling for multiprocessor systems (Ref. 3). Multiprocessor configurations, however, seem to offer no advantages in

In real-time applications, the computer is often required to service programs in response to external signals, and to guarantee that each such program is completely processed within a specified interval following the occurrence of the initiating signal. Such programs are referred to in this paper as time-critical processes, or TCPs. A problem of considerable practical significance in connection with such applications is that of devising scheduling algorithms for servicing multiple time-critical processes. The primary objective of any such algorithm is to guarantee that each TCP can be processed within its allowed interval, taking into account the possible activities of other TCPs. It is clear that, assuming an upper limit can be placed on the repetition rate of the prompting signals, this objective can always be met if, for example, each TCP executes in a separate, sufficiently fast CPU; or, if a single CPU of some high, but finite, execution speed is furnished. Either approach is wasteful in the sense that the CPU (or CPU's) must sometimes remain idle in order to allow for some "worst-case" condition that occasionally may obtain; for example, when all interrupts occur simultaneously. Thus the scheduling problem becomes non-trivial only if additional constraints are imposed. Two such practical constraints are that only one CPU is available, and that the processor idle time is to be minimized. This paper examines four specific scheduling policies, subject to these constraints, and outlines some of the more interesting properties of each. DEFINITIONS Time critical processes

In the context of computing systems, time critical scheduling is the problem of devising efficient CPU 925

From the collection of the Computer History Museum (www.computerhistory.org)

926

Spring Joint Computer Conference, 1972

,-- -



I

C

..

INTERRUPTS

4-

C

I

I

d

T

-

-

-

-

I

+

I

~

Figure I-A model of a time critical process (TCP). The parameters associated with the TCP are the deadline (d), repetition period (T), and required CPU time (C)

the implementation of time critical schedules of the type discussed here. This subject is discussed later. Note, incidentally, that the grouping of interruptdriven processes into entities called jobs is primarily a bookkeeping measure. Such groupings carry certain implications as to the sequence of events before and after the time critical phase of the operation; they are of interest to the loader and accounting mechanisms. From the scheduling viewpoint, however, TCPs are independent entities; it does not matter whether all belong to a single user ("job") or whether sets of one or more TCPs each belong to one of several users. TOP models

Figure 1 is a model of a simple TCP, depicting its repetition period (T), deadline (d), and required compute time (0). The required compute time is the maximum time required to completely process the given TCP on a given CPU, assuming no interruptions. That is, 0 is the amount of CPU service, in terms of CPUseconds, required by the TCP. Evidently, 0 depends on the number and type of executable instructions in the TCP and the speed of the processor. The required compute time may be obtained empirically by timing the process running alone, or it could be predicted by deriving, through such procedure as the Gibson mix, an average instruction execution time for the processor and multiplying this figure by the instruction count of the given process. A basic assumption underlying the study of TCP scheduling is that the external world is insensitive to the actual time at which the process is executed, so long as the process receives 0 CPU-seconds somewhere between the occurrence of the associated interrupt and the deadline. This is typically achieved by incorporating in the process predictive algorithms that extrapolate the results computed from data obtained at time ti to ti+d, when these results are actually transferred out of the computer. T is the repetition period, i.e., the period between

successive occurrences of the interrupt signal associated with the process. In practice, TCPs often are periodic and have d = T = constant; i.e., the constant repetition period and the deadline are identical. The repetition period is often called the frame time. Typical asynchronous TCPs have d < T, and T is variable. N evertheless, these processes may still be represented by the model of Figure 1, as the following considerations show. I t must be possible to define for an asynchronous TCP a minimum T; for if this cannot be done, then either the process cannot be time-critical-namely, it cannot be bound by a hard deadline-or else a processor of infinite execution speed is required. Hence, in the discussions to follow, T is taken to mean either the constant repetition period of a periodic TCP, or the minimum time between interrupts for an asynchronous process. It is generally necessary to assume that TCPs can become active, either periodically or asynchronously, at unpredictable times. Furthermore, it is necessary to assume that no special relationships exist between or may be imposed on the frame times and compute times of the various processes. In practical situations, however, the resolution of the system's timing mechanisms may dictate that all Ts and Os be integer multiples of some basic time unit, so that all Os and Ts are mutually commensurable. This property can be quite significant in devising realistic schedulers. As a rule, time-critical processes require the input of external data before they may proceed, and must allow some time after their completion and before the occurrence of their next interrupt for computed date to be output to external devices. Figure 2 is a model of a TCP of this type. A simple re-definition of the repetition period and deadline (T' and d' in Figure 2) transforms this type to the basic model of Figure 1. This transformation notwithstanding, consideration of I/O requirements complicate the scheduling problem, as will be pointed out later. It is assumed that, apart from an initial input and a final output operations, TCPs do not perform I/O.

I- - - - -



bc= I

,

--, I

_INTERR.UPTS_ -



• c d'

II

I 10 I T'

~

c

J

Figure 2-A TCP with I/O. By transforming the deadline into d' and the repetition period into T' this TCP is made to conform to the basic TCP shown in Figure 1

From the collection of the Computer History Museum (www.computerhistory.org)

Scheduling of Time Critical Processes

927

Load factor

The load factor (L) of a given process is equal to CIT, the ratio of the required CPU time to the repetition period. The load factor is a measure of the CPU load represented by the given TCP. Because the load factor can be readily defined in terms of quantities that are private to a given TCP and are easily obtained, it is natural to seek to establish a clear relationship between the individual load factors and the total CPU load. For instance, it is clear that in the global sense-i.e., over a very long period compared to all the frame times-the sum of the load factors approximates the total CPU load; hence, the condition L> 1 is sufficient to guarantee the failure of all scheduling policies. On the other hand, the condition L:::; 1 is not sufficient to guarantee success, as will be demonstrated shortly. An efficient scheduler will maximize the sum of the load factors without violating any deadlines.

L: L:

Overhead

Overhead is the time required to switch the processor state from one TCP to another. In the following discussions, overhead is assumed to be zero. For that reason a more detailed definition of overhead, which takes into account the variety of possible hardware and software configurations affecting it, is unnecessary. In many practical cases the assumption of zero overhead is a good first approximation, since the state switching time is indeed small compared to the frame times. THE INTELLIGENT FIXED PRIORITY (IFP) ALGORITHM In the most commonly used scheduling technique, each TCP is assigned a fixed priority at the time it enters its time-critical phase-that is, when its associated interrupt is armed and enabled. If the priority levels are such that processes having shorter deadline intervals receive higher priorities, the algorithm is termed "intelligent" fixed priority, to distinguish it from other fixed-priority systems in which the allocation of priority levels is based on other criteria. This should not be taken to mean that the choice of such other criteria is unintelligent; for example, a scheduling policy based on no priorities ("round robin"), or one in which "CPU hogs" receive low priorities, can be quite effective in time sharing environments or in multiprogrammed batch systems. For the time-critical environment relevant to this discussion, the allocation of priorities based on the relative lengths of deadlines is most appropriate. Priorities under IFP need not be truly fixed. In a

TCP1

TCP2

TCP3

TCP4

~ •

I

r•

~

If

T1~1

~ T2

I •

(C;l

I•

C2

~ ~



T3

C 4 T4



Figure 3-Assumed worst case under IFP. Four TCPs are shown, satisfying the conditions that are considered "worst-case" : (a) all interrupts occur simultaneously; (b) the frame times are so related that the CPU must process all TCPs completely within the shortest frame time

multi programmed real-time system, groups of TCPs ("jobs") may enter and leave the system at arbitrary times; the priority structure must be adjusted occasionally in response to such changes in the relative deadlines. Also, real-time processes often go through pre- and post-time-critical phases, during which their priorities may be much lower than the ones they assume in their time-critical phase, again suggesting a dynamic readjustment. An important property of IFP, which has been alluded to in References 1 and 2 but heretofore not substantiated, is that the permissible sum of the load factors must be considerably less than 1 in order to guarantee that each TCP meets its deadline. The higher the number of TCPs to be scheduled, the closer this permissible sum gets to loge 2=0.693. In other words, under IFP, more than 30 percent of the CPU power must remain idle. The following is a sketch of the proof. Assume there are n TCPs, all with constant frame times, and that, at one instant, all of their interrupts occur simultaneously. The CPU at that time is required to provide maximum service in minimum time, so that this condition represents the worst possible case. Furthermore, assume that the frame time of each TCP is related to the next shorter one by T i = T i-1 + Ci-1 where T i - 1 < T i T I , the deadline of TCP 2, d 2, can occur in the frame TI at most once. Now d2 cannot occur in the interval tlt2 since this means that the CPU is idle for some time in that interval; the only exception occurs if d2 = T 2, (since then the CPU can work for TCP2 in the remainder of tl t2 ) ; or if d2 always coincides with either tl or t2, or if d2 always falls in the interval totl' To maintain these restrictions it is necessary that any two occurrences of d2 must be separated by mTI ; therefore T 2 =mTI • I t is tempting to conclude that this condition can be extended to the case of more than two TCPs by requiring di = Ti for all i or Ti=miT I . A proof is not yet available, however. Note that the scheduling property just derived is not responsible for the failure of IFP to schedule more than about 69 percent of the CPU (Figure 3) ; the development of that case remains unchanged if in Figure 3 we let all di = T i. Thus this failure is peculiar to IFP and, in fact, we will show later th~t for d i = T i , the relative urgency (RU) and other algorithms do not suffer from this restriction. THE MINIMAL TIME SLICING (MTS) ALGORITHM In implementing ITS, AT is assumed to be infinitely small. For any given set of TCPs, a time slicing algorithm which retains most features of ITS with a finite AT can be developed. This is the minimal time slicing (MTS) policy. It is based on the realization that, for a given set of TCPs, the smallest time unit of interest

From the collection of the Computer History Museum (www.computerhistory.org)

Scheduling of Time Critical Processes

d

n

...-t

~t---

Figure ~- ?-,he MTS policy in a scheduling intervaL In every schedulmg mterval At, the CPU is allocated in some arbitrary order to all TCPs, such that each receives LiAt CPU-seconds

from the scheduling viewpoint, called a scheduling interval, is the time between the occurrence of two successive "scheduling events." By "scheduling events" ;ve mean events that affect the CPU loading; namely, Interrupt instances and deadlines. The scheduler can guarantee that each TCP meets its de aline by allocating the CPU, in each scheduling interval, in some arbitrary order, according to the load factors. Figure 8 is a graphic illustration of this policy. The practical implementation of MTS requires all TCPs to be periodic so their interrupt instances are predictable. MTS suffers from the same weakness as ITS in scheduling processes for which diT1) with di=T i, whose interrupts coincide at t = O. Construct an MTS for this case, taking care to, in each scheduling interval, assign the CPU to the TCP whose deadline is nearest. No generality is lost since the order is immaterial under MTS. ~et an RU be constructed, and assume that up to scheduling event L, RU and MTS are indeed identical. Consider the event at L and the one following it. There are only three possibilities (see Figure 9) : a) at L we have II (interrupt due to TCP 1) and the next event i~ also t1, b) L = t1, then t2; c) L = t2, then t1. Note that, SInce T2> T 1, it is impossible to have two consecutive t2 without an intervening t1. Now, for the case (a), under RU we would allocate the CPU at L to TCP 1 (its deadline is nearest); it would execute for L1T1 seconds, since the interval M1 is T 1• Since the CPU is assumed 100 percent scheduled, the remainder of t1t1, namely T (1- L 1 ) would be allocated to TCP 2. Since L 1+L2=1, L2=I-L1' so this remainder equals L 2T 1.

(a)

L

t ........- -

THE RELATIVE URGENCY (RU) ALGORITHM The Relative Urgency (RU) policy, developed by M. S. Fineberg and first reported in Reference 1, is similar to MTS in that it requires the scheduler to reevaluate the scheduling environment on every interrupt. RU differs from MTS in that during the period between two successive interrupts, RU is priorityoriented: the highest priority TCP is given control at the start of that period, and allowed to continue until it completes its computation or until the next interrupt. Priorities are re-allocated on every interrupt and are proportional to deadlines as they exist at the interrupt instance (i.e., not simply to their relative lengths) ; the

931

~t

1

(b)

-4--

~t

----+

(c)

Figure 9-Nomenclature for the proof that MTS and RU are equivalent for two TCPs. The proof is by induction, assuming that up to scheduling event L, RU and MTS are identical, and showing that based on this assumption, RU and MTS must also be identical in the interval At

From the collection of the Computer History Museum (www.computerhistory.org)

932

Spring Joint Computer Conference, 1972

This is precisely the division of tlt l, under MTS. For case (b), TCP 2 will receive the CPU, and is short exactly L21lt CPU-seconds, since by the assumption it received L 2 (T2 -IlT) CPU-seconds up to event L. This leaves Ilt (1- L 2) for TCP 1 in Ilt, which is equal to Lillt, again showing the equivalence of RU and MTS in Ilt. Similar conditions apply in case (c). Finally, at t = 0 we have case (a) (with L = tl = t2) but for this case we already showed that RU =MTS. Hence the assertion is proved by induction. There is considerable empirical evidence that RU is capable of scheduling the CPU at 100 percent efficiency for all Ti/T i - l ratios when all di = T i ; in this case, RU is at least as efficient as MTS or ITS (more efficient in fact, due to lower switching overhead) ; when the Ti are not integer multiples of TI (the shortest frame time), IFP is known to be less efficient than either MTS, ITS or RU. When di < T i , RU is capable of scheduling more of the CPU than MTS or ITS, i.e., more TCPs can be accommodated under RU.

number of TCPs n is not a multiple .of the number of CPUs m, there will remain one TCP that cannot be accommodated within Ilt using m processors, whereas the fast processor accommodates all TCPs within Ilt. Furthermore, if Grosch's Law holds, the faster CPU should cost less than the m slower units, so that even from the economic standpoint, multiprocessor systems do not appear desirable. CONCLUSION This paper presented primarily heuristic extensions and generalizations of concepts that were for the most part first sketched in Reference 1. Much work remains to be done in strengthening and extending the proofs and in discovering the properties of scheduling with I/O constraints. The relation between RU and MTS is particularly intriguing. A consistent theory of scheduling of time-critical processes is within reach. ACKNOWLEDGMENT

REGARDING MULTIPROCESSING Considerable effort has been expended on timecritical scheduling techniques for multiprocessor systems (e.g., References 3 and 4). For TCPs of the type considered in this paper, multiprocessor systems do not offer any advantages (if one excludes redundancy or backup requirements). In fact, it appears that in some cases, multiprocessor systems are definitely less desirable than an "equivalent" single processor. By "equivalent" is meant that each of m CPUs execute at a rate l/m as fast as the single CPU. Given m processors and n TCPs (m < n) with equal Ci and such that all n TCPs can be executed serially on the single, fast processor in time Ilt. Then each of the m processor can completely process at most p TCPs, where p is an integer that satisfies p (Ilt/ n) m

Suggest Documents