ENGG4420 ‐‐ CHAPTER 5 ‐‐ LECTURE 1 · ENGG4420 ‐‐CHAPTER 5 ‐‐LECTURE 1...

REAL‐TIME TASKS SCHEDULING IN MULTIPROCESSOR AND DISTRIBUTED SYSTEMSAND FAULT TOLERANCE

Real‐time scheduling on multiprocessors and distributed systems is much more difficult ‐‐determining an optimal schedule for a set of real‐time tasks on a multiprocessor or a distributed system is an NP‐hard problem.

•

The interprocess communication (IPC) is inexpensive and can be ignored in comparison to task execution times

○

May use a centralized dispatcher/scheduler that requires that the system maintains the state of various tasks of the system in a centralized data structure.

○

Multiprocessor systems are known as tightly coupled systems ‐‐ shared physical memory present in the system

•

IPC times are comparable to task execution times○Cannot use a centralized dispatcher/scheduler ‐‐communication to update the centralized data structure ‐‐ too costly.

○

Distributed systems are called loosely coupled ‐‐ no shared physical memory present

•

ENGG4420 ‐‐ CHAPTER 5 ‐‐ LECTURE 1November‐26‐129:46 AM

CHAPTER 5 By Radu Muresan University of Guelph Page 1

SCHEDULING REAL‐TIME TASKS on distributed and multiprocessor systems consists of two subproblems:

The task assignment problem is concerned with how to partition a set of tasks and then how to assign these tasks to processors ‐‐ task assignment can be: 1) static or 2) dynamic.

a.

In the static allocation scheme, the allocation of tasks to nodes is permanent and does not change with time.

b.

In the dynamic task assignment, tasks are assigned to the nodes as they arise ‐‐ different instances of tasks may be allocated to different nodes.

c.

Task allocation to processors1.

Uniprocessor scheduling algorithms can be used for the task set allocated to a particular processor.

a.Scheduling of tasks on the individual processors2.


ENGG4420. CHAPTER 4: Uniprocessor and Multiprocessor Scheduling. Developed by Radu Muresan, Univesity of Guelph 14

Multiprocessor Schedule

The vast majority of assignment/scheduling problems on systems with more than two processors are NP-complete. We must therefore use heuristics.

Development of multiprocessor schedule is divided into two steps: assign tasks to processors; run a uniprocessor schedule for each processor.

Make an allocation

Schedule each processor based on

allocation

Are all theseschedule feasible?

Outputschedule

Check stoppingcriteria

Declarefailure

Changealloca-

tion

continue

stop

Most algorithms that are deployed in practice for multiprocessor scheduling are heuristic algorithms.Most heuristics are motivated by the fact that the uniprocessor scheduling (i.e. scheduling a set of tasks on a single processor) problem is usually tractable. If one or more of the schedules turn to be infeasible, then we must either return to the allocation step and change the allocation, or declare that a schedule cannot be found and stop -- the steps are presented in the diagram of this slide

•

Many variations of this approach are possible; for example, one can check for schedulability after the allocation of each task.

•

NP-complete: can’t be solved by an algorithm in polynomial time.


MULTIPROCESSOR TASK ALLOCATION

Utilization Balancing Algorithm1.Next‐Fit Algorithm for RMA2.Bin Packing Algorithm for EDF3.

STATIC ALLOCATION ALGORITHMS ‐‐ the tasks are pre‐allocated to processors ‐‐ no overhead incurs during run time since tasks are permanently assigned to processors at the system initialization time.

Focussed Addressing and Binding (FAB) 1.The Buddy Strategy Algorithm2.

DYNAMIC ALLOCATION ALGORITHMS ‐‐ in many applications tasks arrive sporadically at different nodes ‐‐ the tasks are assigned to processor as and when they arise ‐‐ the dynamic approach incurs high run time overhead since the allocator component running at every node needs to keep track of the instantaneous load position at every other node.

The task allocation algorithms for multiprocessors do not try to minimize communication costs as interprocess communication time is low ‐‐ communication time is the same as memory access time.The above algorithms may not work satisfactorily in distributed environments



Utilization-Balancing Algorithm

This algorithm attempts to balance processor utilization, and proceeds by allocating the tasks one by one and selecting the least utilized processor.

1. For each task Ti, do Allocate one copy of the task to each of the ri least utilized

processors.

Update the processor allocation to account for the allocation of task Ti.

end do

endwhere ri is the redundancy, i.e., the number of copies of task i that must be scheduled.


In a perfectly balanced system the utilization ui at each processor equals the overall average utilization u of the processors of the system. For a set of tasks STi assigned to a processor Pi we have:

Maintains the tasks in a queue in increasing order of their utilizations.

•

It removes tasks one by one from the head of the queue and allocates them to the least utilized processor each time.

•

The objective of selecting the least utilized processor is to balance the utilization of different processors.

•

UTILIZATION BALANCING ALGORITHM



A Next-Fit Algorithm for RM-Scheduling

Task set properties: independence, preemptibility, and periodicity

Other assumptions: identical processors tasks require no resources other than processor time.

Define M > 3 classes as follows: Task Ti is in class j < M if:

We allocate tasks one by one to the appropriate processor class until all the tasks have been scheduled, adding processors to classes if that is needed for RM-sched.

12/12 /1)1/(1 jii

j Pe

This is a utilization‐based allocation heuristic.•The task set has the same properties as for the RM uniprocessor scheduling algorithm (i.e., independence, preemptibility, and periodicity).

•

M is picked by user. •Corresponding to each task class is a set of processors that is only allocated to tasks of that class.

•

It is possible to show that this approach uses no more than N times the minimum possible number of processors, where:

•

otherwise340.2

]5.0,12(in n utilizatioith not task w is thereif911.1N



Exampleclass Bound

C1 (0.41, 1]

C2 (0.26, 0.41]

C3 (0.19, 0.26]

C4 (0.0, 0.19]

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11

ei 5 7 3 1 10 16 1 3 9 17 21

Pi 10 21 22 24 30 40 50 55 70 90 95

u(i) 0.5 0.33 .14 .04 .33 .40 .02 .05 .13 .19 .22

Cls. C1 C2 C4 C4 C2 C2 C4 C4 C4 C4 C3

Note: u(i) = ei/Pi; Solution presented on the overhead

Suppose we have M = 4 classes. The table lists the utilization bounds corresponding to each class

Since we have at least one task in each of the four classes, let us begin by earmarking one processor for each class.

•

In particular, let processor pi be reserved for task in class Ci, 1 ≤ i ≤ 4.

•



A Bin-Packing Assignment Algorithm for EDF

Problem. Schedule a set of periodic independent preemptible tasks on a multiprocessor system consisting of identical processors. the task deadlines equal their periods tasks require no other resources

Solution: EDF-scheduling on a processor: if U < 1 (for the task set

assigned to the processor) => the set is schedulable on the processor

The problem reduces to making task assignments to processors with the property that U < 1.



First-Fit Decreasing Algorithm

Initialize i to 1. Set U(j) = 0, for all j.

while i ≤ nT doLet j = min{k|U(k) + u(i) ≤ 1}.

Assign the ith task in L to pj.

i ← i + 1.

end while

We would like to minimize the number of processors needed. This is the famous bin‐packing problem and many algorithms exist for solving it. In this algorithm, j selects the first processor that meats the schedulability inequality.

•

The algorithm we present here is the first‐fit decreasing algorithm. Suppose there are nT tasks to be assigned.

•

Prepare a list L of the tasks so that their utilizations (i.e., u(i) = ei/Pi) are in decreasing order.

•



Example

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11

ei 5 7 3 1 10 16 1 3 9 17 21

Pi 10 21 22 24 30 40 50 55 70 90 95

u(i) 0.5 0.33 0.14 0.04 0.33 0.40 0.02 0.05 0.13 0.19 0.22

The ordered list L is:L = (T1, T6, T2, T5, T11, T10, T3, T9, T8, T4, T7)The assignment is presented in the next slide.


Solution

Step Ti u(i) Assign to Post-assignment U vector

1 T1 0.50 p1 (0.50)

2 T6 0.40 p1 (0.90)

3 T2 0.33 p2 (0.90, 0.33)

4 T5 0.33 p2 (0.90, 0.66)

5 T11 0.22 p2 (0.90, 0.88)

6 T10 0.18 p3 (0.90, 0.88, 0.18)

7 T3 0.14 p3 (0.90, 0.88, 0.32)

8 T9 0.13 p3 (0.90, 0.88, 0.45)

9 T8 0.06 p1 (0.96, 0.88, 0.45)

10 T4 0.04 p1 (1.00, 0.88, 0.45)

11 T7 0.02 p2 (1.00, 0.90, 0.45)

The vector U = (U1, U2, U3, …) contains the total utilizations of processor pi in Ui.

•

It is possible to show that when the number of processors required is large, the ratio:

•

(number of processors used by the first‐fit decreasing algorithm)/(number of processors used by optimal algorithm) approaches 11/9 = 1.22, when a large task set is used. In fact, this limit is approached quickly, so that 1.22 is a good measure even for relatively small systems.

•


FOCUSED ADDRESSING AND BIDDING (FAB)ALGORITHM

FAB is a simple algorithm that can be used as an on‐line procedure for task sets consisting of both critical and non‐critical real‐time tasks.Critical tasks must have sufficient time reserved for them so that they continue to execute successfully, even if they need their worst‐case execution time.

•

The non‐critical tasks are either processed or not, depending on the system's ability to do so.

•

The guarantee can be based on the expected run time of the task rather than the worst‐case run time (noncritical task).

○

THE UNDERLYING SYSTEM MODE IS: when a noncritical task arrives at processor pi, the processor checks to see if it has the resources and time to execute the task without missing any deadlines of the critical tasks or the previously guaranteed noncritical tasks ‐‐ if yes, pi accepts this new noncritical task and adds it to its list of tasks to be executed and reserves time for it.

The FAB ALGORITHM IS USED WHEN pi determines that it does not have the resources or time to execute the task ‐‐ in this case, it tries to ship that task out to some other processor in the system.

•


THE FAB ALGORITHM WORKS AS FOLLOWS

STATUS TABLE indicates which tasks have been already committed to run including the set of critical tasks (which were preassigned statically), and any additional noncritical tasks that have been accepted ‐‐ execution time and periods of the tasks.

○

LOAD TABLE contains the latest load information of all other processors of the system ‐‐ the surplus computing capacity available at the different processors can be determined.

○

Every processor maintains two tables called: status table and system load table.

•

Every processor on receiving a broadcast from a node about the load position updates the system load table.

○

Since the system is distributed, this information may never be completely up to date.

○

As a result, when a task arrives at a node, the node first checks whether the task can be processed locally ‐‐ if yes, it updates its status table if not, it looks for a processor to offload the task.

○

THE TIME AXIS is divided into windows, which are intervals of fixed duration ‐‐ at the end of each window, each processor broadcasts to all other processors the fraction of computing power in the next window for which it has no committed tasks

•


THE PROCESS OF OFFLOADING A TASK is based on the content of the system load table ‐‐ an overloaded processor checks its surplus information and:Selects a processor (called the focused processor) ps that is believed to be the most likely to be able to successfully execute that task by its deadline.

1)

The RFB contains the vital statistics of the task ‐‐its expected execution time, any other resource requirements, its deadline, etc.

a.

The system load table information might be out of date ‐‐ the overloaded processor, as insurance against this, will decide to send requests for bids (RFB) to other lightly loaded processor in parallel with sending out the task to the focused processor ps ‐‐ this is to gain time in case ps refuses the task.

2)

The RFB asks any processor that can successfully execute the task to send a bid to the focused processor ps stating how quickly it can process the task.

3)

An RFB is only sent out if the sending processor ps estimates that there will be enough time for timely response to it.

4)

Specifically, two times tbid and toffload are calculated ‐‐if tbid ≤ toffload then the RFB is sent out.

5)


TIME CALCULATIONS BY FAB ALGORITHM:tbid = (estimated time taken by RFB to reach its destination) + (the estimated time taken by the destination to respond with a bid) + (the estimated time taken to transmit the bid to the focused processor);

•

If tbid ≤ toffload; then RFB is sent out.○

toffload = (task deadline) ‐ [(current time) + (time to move the task) + (task‐execution time)];

tarr = (current time) + (time for bid to be received by ps) + (time taken by ps to make a decision) + (time taken to transfer the task) + (time taken by pt to either guarantee or reject the task);

First will estimate when the new task will arrive and how long will take to be either guaranteed or rejected:

○

tcomp = (time allotted to critical tasks in [tarr, D]) + (time needed in [tarr, D] to run already‐accepted noncritical tasks] + (fraction of recently accepted bids)x(time needed in [tarr, D] to honor pending bids);

tsurplus = D ‐ (current time) ‐ tcomp;

Next calculates the surplus time between the absolute deadline D, current time, and the computational time spoken for in the interval [tarr, D]:

○

If the task worst‐case run times are used the bids will be very conservative; if the average‐case values are used, the bids will be less conservative.

○

When a processor pt receives an RFB, it checks to see if it can meet the task requirements and still execute its already‐scheduled tasks successfully.

•


COURSE OF ACTION ‐‐ if tsurplus < (task execution time), then no bid is sent out ‐‐ if tsurplus ≥ (task execution time), pt sends out a bid to ps (the focus processor);The bid contains tarr, tsurplus, and an estimate of how long a task transferred to pt will have to wait before it is either guaranteed or rejected;

•

All bids are sent to the focused processor ps ‐‐ if ps is unable to process the task successfully, it can review the bids it gets and see which other processor is most likely to be able to run the task, and transfer the task to that processor;

•

ps waits for a certain minimum number of bids to arrive or until a specified time has expired since receiving the task ‐‐ for each bidding node pi, ps computes the estimated arrival time η(i) of the task at that node.

•

Denotes by tsurplus(i) and tarr(i) the tsurplus and tarr values contained in the bid received from pi.

•

Then, ps computes the following:•


CARDINAL RULE IN BIDDING ‐‐ no new noncritical task can be allowed to cause any critical or previously guaranteed noncritical task to miss its guaranteed deadline.WAYS TO ASSES the schedulability of newly arrived tasks:Introduce into the schedule a periodic task that checks for schedulability every t seconds.

1.

A similar flag can be used to decide if there is enough time to respond to an RFB.

a.

Set a flag that indicates if the processor has time to check the schedulability of a new task and still meet all guaranteed deadlines ‐‐ if the flag is set when a new task arrives, the executing task is preempted and the processor deals with this new task ‐‐ if the flag is reset the processor cannot be interrupted and the new task must wait.

2.


THE BUDDY STRATEGY

The buddy strategy tries to solve the same problem as the FAB algorithm ‐‐ soft real‐time tasks arrive at the various processors of a multiprocessor and, if an individual processor finds itself overloaded, it tries to offload some tasks onto less lightly loaded processors.The buddy strategy differs from the FAB algorithm in the manner in which the target processors are found

•

STRATEGY: Each processor has 3 thresholds of loading: under loaded (TU), fully loaded (TF), and over loaded (TV).

1.

State U (underloaded) if Q ≤ TU;a.State F (fully loaded) if TF < Q ≤ TV;b.State V (overloaded) if Q > TV;c.

The loading is determined by the number of jobs awaiting service in the processor's queue. If the queue length is Q, the processor is said to be in:

2.

If in state U a processor is in a position to execute tasks transferred from other processors ‐‐ if in state V, it looks for other processors on which to offload some tasks ‐‐ if in state F will neither accept nor offload tasks from/to other processors.

3.

When a processor makes a transition out of or into state U, it broadcasts an announcement to this effect.

4.


THE TRANSITION to/from state U is broadcasted to a limited subset of processors called processor's buddy set ‐‐ each processor is aware of whether any member of its buddy set is in state U ‐‐ if it is overloaded, it chooses an underloaded member (if any) in its buddy set on which to offload a task.ISSUES RELATED TO THE BUDDY SET

If a multihop network is used and the buddy set is restricted to processors that are "close" to it (in terms of the number of hops between them), there will be a substantial saving of network bandwidth ‐‐keeping the size of the buddy sets constant (some simulation experiments show 10 ‐ 15 for buddy set size) and independent of the system size results in the constant traffic per processor when state‐updated occurs.

a.

How the buddy set is to be chosen in a multi hop network? ‐‐ if too large the state‐change broadcast will heavily load the interconnection network ‐‐ if too small the success of finding an available U state processor will diminish.

1.

SOLUTION to reduce the probability of the above happening: construct an ordered list of preferred processors ‐‐ first list processors that are only one hop away from the processor, then those that are two hops away, etc.

a.

If a node is in the buddy set of many overloaded processors, and it delivers a state‐change message to them saying that now is underloaded ‐‐ this can result in each of the overloaded processors dumping their load on this one processor and make it overloaded.

2.


Simulation experiments have shown that setting TU = 1; TF = 2; and TV = 3 produces good results for a wide range of system parameters;

a.

Which threshold are best for a given system depends on the particular characteristics of that system, including the size of the buddy set, the prevailing load, and the bandwidth and topology of the interconnection network.

b.

THE CHOICE OF THE THRESHOLDS TU, TF, AND TV ‐‐ in general, the greater the value of TV, the smaller the rate at which tasks are transferred from one node to another

3.


ASSIGNMENT WITH PRECEDENCE CONDITIONS

Algorithm that assigns and schedules tasks with precedence conditions and additional resource constraints ‐‐ basic algorithm idea is to reduce communication costs by assigning (if possible) to the same processor tasks that heavily communicate with one another.UNDERLYING TASK MODEL: each task may be composed of one or more subtasks ‐‐ the release time of each task and the worst‐case execution time of each subtask are given ‐‐the subtask communication pattern is represented by a task precedence graph ‐‐ we are also given the volume of communication between tasks ‐‐ it is assumed that if subtask s1 sends output to s2, this is done at the end of s1;

Associated with each subtask is a latest finishing time (LFT) that will be explained through an example;

•

The algorithm is a trial‐and‐error process ‐‐ assign subtasks to the processors one by one in the order of their LFT values ‐‐ for same LFT the subtask with the greatest number of successor wins.

•

Check for feasibility after each assignment ‐‐ if one assignment is not feasible try another one, etc.

•

When subtasks communicate a lot, if possible, they are assigned to the same processor.

○

A threshold policy kc is followed when to characterize the volume of communication between tasks.

•


EXAMPLE: Consider the task graph below with the execution times described in the table. The labels within the circles are the subtasks subscripts and the arc labels denote the volume of communication between tasks. Suppose the overall deadline for this task (i.e., the deadline of subtask s4) is 30. Assume that s1, s2, and s2 are run in parallel. Calculate LFT for tasks and consider a threshold policy with kc = 3. Apply the algorithm to this task set.


kc is a TUNABEL PARAMETER ‐‐ if kc is 0, then intersubtask communication will not be taken in consideration when we do the assignment ‐‐ if kc is too high, then most of the time, we will be forced to assign tasks to the same processor and this may result in an infeasible schedule ‐‐ when we obtain an infeasible schedule we are forced to reduce kc adaptively to relax this condition.

Start with the set of tasks that need to be assigned and scheduled. Choose a value for kc and determine, based on this value, which tasks need to be on the same processor.

1.

Start assigning and scheduling the subtasks in order of precedence. If a particular allocation is infeasible, reallocate if possible. If feasibility is impossible to achieve because of the tasks that need to be assigned to the same processor, reduce kc suitably and go to the previous step ‐‐

2.

STOP when either the tasks have been successfully assigned and scheduled, or when the algorithm has tried more than a certain number of iterations ‐‐ in the former case, output the completed schedule; in the latter, declare failure.

3.

The algorithm can be described as follows:•


ASSIGNMENT

Consider a system composed of one task that is subdivided into 8 subtasks. The table below gives the execution times and the deadline for the output to the outside world. The task graph is presented in figure below. The task graph indicates the precedence and the communication volume. Apply the algorithm presented in the previous slide and come up with a feasible schedule. Note that the value of kc can be relaxed in order to obtain a feasible constraint. Calculate the LFT values for all subtasks. For generating a feasible schedule start with kc = 1.5.


Date post:	27-Jun-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

ENGG4420 ‐‐ CHAPTER 5 ‐‐ LECTURE 1 · ENGG4420 ‐‐CHAPTER 5 ‐‐LECTURE 1...

Documents