Chapter 3. Online Scheduling of Moldable Jobs with Deadline
3.1 Dynamic Scheduling Approaches
This section presents four dynamic scheduling approaches for moldable jobs with deadline. These four approaches are designed in a flexible way which allows them to cooperate with different waiting queue sequencing policies, such as Earliest Deadline First (EDF) [27], Least Laxity First (LLF) [32], and Shortest Job First (SJF) [33]. When jobs are submitted to the waiting queue, they are sorted in a non-increasing order of their priorities which are determined by the above waiting queue sequencing policies. The scheduling activities will occur on two types of system events: job-submission and job-finish. A job-submission event occurs when a user submits a new job into the waiting queue, while a job-finish event indicates that some running job finishes its execution and releases the resources used by it. On such events, the job scheduler then repeatedly tries to allocate each job according to the sequence in queue. Each time the scheduler gets the first job in queue and then checks whether the first job can meet its deadline with currently available processors or not. If not, the scheduler can take different actions to deal with the situation, leading to different scheduling approaches. In the following, we present four possible approaches for handling such situation.
In the first approach (Delete Immediately Algorithm), if the first job cannot meet the deadline with currently available processors, it is simply discarded and marked as missed before the scheduler proceeds to the next job in queue. The approach is described in detailed in the following DI Algorithm. The scheduling activities will occur on job-finish events and job-submission events where the newly submitted job becomes the first job in the waiting queue.
Delete Immediately Algorithm
It is possible that a job cannot meet the deadline under currently available processors, but would be able to meet deadline later because more processors become available due to resource release by currently running jobs. Taking this into consideration, we propose the second dynamic scheduling approach (First Meet Algorithm) which keeps the first job in queue for later re-checking when it cannot meet the deadline at the moment and proceeds to handle subsequent jobs in queue. The first job will be re-considered in the future scheduling activities when some running jobs finish and release occupied resources. FM Algorithm in the following describes the approach in details. The scheduling activities will occur on job-finish
events and job-submission events where the newly submitted job becomes the first job in the
In the second approach, the scheduler would proceed to handle subsequent jobs in queue when the first job cannot meet the deadline with currently available processors. This arrangement allows out-of-order execution and has the potential to improve resource
utilization. However, out-of-order execution runs the risk of raising the probability of missing deadline for the first job. Therefore, in the following we propose the third approach which is a compromise between the first and the second approaches. In this approach, when the first job cannot meet the deadline with currently available processors, the scheduler will check whether future resource releases by currently running jobs would allow the job to meet its deadline. If yes, the first job would be kept in queue. However, unlike in the second approach, out-of-order execution is not allowed in this approach in order to ensure that the first job can meet the deadline finally. On the other hand, if the result of the checking is no, the first job would be simply deleted just like in the first approach. In the following, RB Algorithm describes this approach in details. The scheduling activities will occur on job-finish events and job-submission events where the newly submitted job becomes the first job in the waiting queue.
13 else
22 Sort the running jobs in a non-decreasing order of their expected finish time;
23 Tfinish = the expected finish time of the first running job; planning of all queued jobs to make better scheduling decisions and requires re-planning upon new job submission. It is still a dynamic scheduling approach since only the jobs already submitted to the waiting queue at that moment will be considered in the scheduling process, not the entire jobs during the whole system operation period. Once the full-ahead plan of the queued jobs is established after a specific scheduling activity, those jobs will be executed in order at the planned time instant with the reserved number of processors according to such plan until a new job is submitted to the waiting queue, which will trigger a partial
re-scheduling activity described in the following Prescheduling Algorithm. The full-ahead planning in Prescheduling Algorithm tries to reserve the smallest number of enough processors for a job to meet its deadline. This arrangement is expected to improve resource utilization since the efficiency of a parallel job usually drops as the number of processors used increases. For the fourth approach, scheduling activities will occur on job-submission events only since on job-finish events the waiting jobs can be executed in sequence according to the previous execution plan without new scheduling efforts.
Prescheduling Algorithm Variables:
NP: total number of processors in the system;
releaseQueue: storing the expected job-finish events for the scheduling plan of the queued jobs;
1 index = the index of the newly submitted job in waiting queue;
2 Clear the resource reservations for those jobs with indices larger than index;
3 for (i=index ; i<LengthOfWaitingQueue ; i++)
14 Initialize releaseQueue with job-finish events of current running jobs and jobs to i-1;
15 while (releaseQueue is not empty)
This section presents some examples for illustrating how the algorithms proposed in the previous section work and discusses the relative strength of each algorithm. In the following examples, the policy of waiting queue sequencing is EDF and the speedup model of jobs is assumed to be linear [34]. Job a in the following figures indicate a job that is already running in the system.