CHAPTER 4: SOFTWARE PART OF RTOS, THE SCHEDULER

Transcription

1 CHAPTER 4: SOFTWARE PART OF RTOS, THE SCHEDULER To provide the transparency of the system the user space is implemented in software as Scheduler. Given the sketch of the architecture, a low overhead scheduler is needed that maps application tasks on the available resources in most efficient manner. Periodic scheduling of tasks for variable number of channels requires certain set of data, may also require program code and other parameters such as channel states from previous cycle. Furthermore, depending on the type of tasks it may undergo a series of processes on different essors. The timely completion of each of these sub-processes requires availability of appropriate program code, the relevant datum and states, and certain amount of processing resource. From the perspective of the overall system, these requirements equate to allocating system resources, including essors, memory, and the interconnections (buses, and peripherals) in a timely manner. In the designed Scheduler, the combined sub-processes are scheduled at one time slot, however, they are treated as individual tasks assigned on different essor to exploit coarse grain parallelism where a channel application is pipelined and mapped on multiple essors running sequentially. Application pipelining framework is based on the concept of components or task model similar to instruction pipelining in the essor. Here, sequential sets of operations are partitioned into separate tasks that could run sequentially on different set of essors performing operations on their own set of data and using their own program code as independent processes. In this framework, each task is characterized with its own attributes comprising of periodicity, deadline and a worst-case execution time. All these attributes are static, i.e. specified at design time

2 This framework enables user to break large application into smaller, modular sub-processes (tasks) and run any number of these tasks in whatever order required on different essors for different processes/channels. It further allows reusability of the component program which can be used in the same application for different channels or in different application with similar tasks. Media applications are the natural candidate of such framework where application can be partitioned into independent processes and mapped on different set of essors to run sequentially. Figure 2 presents a pictorial view of an application partitioned into sets of tasks sequentially executing on six essors as pipelined application. Time essor 1 essor 2 essor 3 essor 4 essor 5 essor 6 essn TaskA essn TaskA essn+1 TaskE TaskG TaskG TaskG essn+3 TaskA essn+3 TaskA essn+4 TaskA essn+4 TaskA essn TaskA essn TaskA essn TaskB essn+1 TaskF essn+1 TaskF TaskH TaskH TaskH essn+3 TaskF essn+3 TaskF essn+4 TaskB essn TaskB essn TaskC essn TaskC essn+1 TaskC essn+1 TaskC TaskJ TaskJ TaskJ essn+3 TaskN essn+4 TaskN essn TaskC essn TaskC essn TaskD essn TaskD essn+1 TaskD essn+1 TaskD TaskM TaskM TaskM essn+3 TaskX essn+4 TakP essn TaskD essn TaskD essn TaskR essn+1 TaskU essn+1 TaskU een+2 TaskY essn+3 TaskY essn+3 TaskY essn+3 TaskR esn+4 TaskU essn+4 TaskU essn TaskU essn TaskU Figure 2: Software Framework Example of Application Pipeline on Six essors essn TaskS essn+1 TaskW essn+1 TaskW TaskZ TaskZ TaskZ essn+3 TaskS essn+4 TakW essn+4 TakW essn TaskW

3 The framework software architecture performs the execution as two-level scheduling algorithm. Each level can follow different scheduling policy. On the targeted multiprocessor system, the first level applies a preemptive policy and ensures meeting the timing constraints. The second level applies hierarchal scheduling policy using the tasks knowledge and ensures quality of service. As noted in Chapter Two, in the targeted architecture the system has a matrix of essors with dedicated cache memories, connected by distributed Communication Controller, Switch and DMA to the main memory, therefore, the Scheduler attempts to map tasks first to essors most likely to share cache memory at the same level from related tasks. Each component of distributed Communication Controller (CC) has its own queue for primary task assignments through which the Scheduler makes the initial affinity assignment. In the presence of large number of processes/channels and their sub-processes/tasks, ensuring that the system meets the requirements of all the channels coordination among different components of system and command and control procedure is required that can streamline the overall process, such that the resources are utilized most efficiently and at the same time all tasks requirements are also met. To summarize, the Scheduler job could be defined as following. ess P i is to be scheduled at regular Time interval T i that requires sparse Data D i, program Code C i and Execution time E i that maximize the resource utilization and minimize the end-to-end delay. This process may need to be mapped on a single essor or a set of essors

4 Thus, the job of the scheduler is to optimize the resource utilization by minimizing data transfer overhead and find the right tradeoff between minimizing wait time for the essor and increasing the system throughput in terms of number of channels it can process Scheduling algorithms for real-time systems are focused on guaranteeing the system timing constraints with advance knowledge. Different scheduling policies set different configuration or a priori knowledge requirement for tasks. For example, in the cyclic executive scheduling, an explicit schedule or calendar is set at configuration which determines which task has to be executed at any particular instant. In the fixed priority scheduling, the scheduler assigns a fixed priority to each task; and at run time, the scheduler dynamically assigns the essor to the task with the highest priority. In the dynamic priority policy, no priori knowledge exists and the run-time policy selects the ready task with the earliest deadline for execution. For implementing the application tasks on the targeted multiprocessor architecture, the software framework requires tasks to be periodic and having a known maximum execution time. This corresponds to the a priori knowledge of the system being able to meet its timing constraints and assignment of fixed priorities. To support runtime scheduling, heuristic scheduler is used at the second level which establishes the criterion based on task information. In order to provide this predictability, scheduling impose certain constraints on the system. In the following, the constraints of the system are more specifically described. Some of these constraints are satisfied using the scheduler and others by the service discipline. Some of the basic and more apparent constraints are following:

5 1. Assign resources to each process/channel, such that its periodic processing is completed before a stipulated time (deadline) 2. The total assignment to a essor, a memory, or any other system resource, must not exceed its capability 3. Scheduling decisions is made in advance of the beginning of acquisition of a datum, to permit for re-programming of the DMA channel and any other arrangements that the Switch must make. 4. Scheduler must cluster the tasks of similar type together. Tasks of same type use same program code, if same types of tasks are scheduled back-to-back, the time associated with loading program code is saved, minimizing program fetch overhead. 5. Another subtle constraint peculiar to the targeted architecture is to concatenate the same tasks, but not at the cost of increasing Arbitration Load (AL) on the memory interface beyond its capacity causing degradation in QoS of other processes/channels. 6. Keep minimum possible number of essors active to minimize the power dissipation, i.e. keep the rest of the essors in sleep mode as long as system is not running at full capacity. In the developed scheduler, time period is divided in time slots and each time slot has a defined maximum AL limit. When considering scheduling a channel on a particular time slot, the scheduler calculates the new load estimates (slack) for the time slots in which the new task is scheduled based on heuristics. If the channel scheduled next executes a different task from the current channel, it updates the AL due to possible increase in - 3 -

6 configuration fetch requests. If scheduling the new channel does not cause the AL in any time slot to exceed the AL limit, then the task is scheduled there. If, however, the new AL in any time slot does exceed the specified limit, this means that processing will not be completed at the estimated time because of an arbitration bottleneck. Scheduling the channel anyway may cause a drop in the QoS of adjacently scheduled channels. Consequently, the new channel is not scheduled in the time slot and the scheduler moves on to the next best time slot. Considered Scheduling Policies Rate Monotonic Scheduling (RMS) and many of its variants are well suited for scheduling periodic tasks in real-time systems and list scheduling alternatives also offer better choices. These include, Earliest Deadline First (EDF), Earliest Start-time First (EST), Dynamic Deadline Modification (DDM), and Earliest Deadline-start Time (EST). However, existing scheduling tests for these disciplines assume single processor systems. Moreover, these disciplines do not favor the cache-affine assignments, or try to minimize the delay. Hence, only fixed priority driven system cannot meet the requirements. Squillante et al. [32] analyze a number of techniques for cache-affine assignments in multiprocessor environments. Although, they do not address real-time systems, their proposed scheduling policies, Minimum Intervening, and Limited Minimum Intervening, and Limited Minimum Intervening Routing, provide useful insight. Jonsson et al. [33] propose a modified EDF scheduling policy that favors cache-affine assignments when applied with tasks of same deadline. Chandra, et al [34] have presented hierarchical scheduling algorithm for multiprocessor based system, however, it is focused on symmetric processors only

7 With this pretext, a two level scheduling policy is adapted for mapping high density channels with variable deadlines on heterogeneous multiprocessor system that meets the constraints and characteristics defined by the software framework. The first level applies a fixed-priority preemptive scheduling policy to tasks. This policy permits guaranteeing the application timing constraints. At this level, the essors available resources are claimed to detect the intervals where the other tasks could be inserted. The second level uses heuristic that takes quality characteristics and the dynamic situation of the environment in to account and effectively adapts to application behavior. There are different considerations for clustering, such as minimizing communication overhead, load balancing, or random. Here, clustering heuristic is based on maximizing cache-affine assignments, while meeting the deadline and capacity constraints. The specific policy at this level is only proposed as recommended for media application, and designers can choose other suited policy for their application. Variants of Rate Monotonic algorithms [35-37] have also been used as second level schedulers and performance has been compared with their implementation as second level scheduler. essor utilization enhances and reduction in program fetch overhead is observed when Rate Monotonic algorithm is preceded by fixed priority preemptive scheduling. This two level scheduling policy offers flexibility at runtime for different application and ensure timing constraints guarantee by enforcing fixed-priority preemptive scheduling at first level. This two level scheduling policy adds computational overhead for distinguishing

8 first iteration from the rest of the iterations for each channel. However, this can be maintained locally in memory table. Furthermore, since in every iteration only one of the two schedulers is used for tasks assignment, two level scheduling policy does not add any processing overhead at runtime. The first level scheduler performs required actions for scheduling different processes of the application, which is analogous to the regular run-time scheduler in traditional real-time systems. The componets and their respective activities at first level scheduler, using fixed priority preemptive scheduling are the following. Task Handler Releases tasks on different essors for different channels/processes according to the defined period (a priori knowledge) and continue to do so until the process is killed. Time Slot Selector The scheduler dynamically keeps track of the slack time available in each time slot to insert new tasks for different process/channel. This information is gathered in the second level scheduler and accessible at the first level scheduler. Concatenating of Similar Tasks Every time a new channel is created/opened, its processes and their corresponding tasks need to be scheduled. The scheduler evaluates the task requirements and concatenates similar tasks to schedule at the same time slot as long as it meets the system subtle requirement. The Scheduler is best described by the following listing, Listing Find new task from task queue with highest priority

9 2. Assign to next_task the ID of new task 3. Identify resource requirement 4. Find all the time slots with scheduled similar task 5. If no time slot is available with similar tasks go to Find slack time at the first available time slot 7. Run acceptance test for scheduling at the current time slot 8. If test passes concatenate new task with other tasks scheduled on the time slot 9. Schedule new tasks along with other task when time slot arrives 1. Done with first time schedule, update the field for subsequent arrival and scheduling of this task 11. Go to second level of scheduling 12. If acceptance test fails, choose next available time slot 13. If no time slot available go to Go to Find any time slot with slack greater than AL 16. If no time slot system running at full capacity no room for further tasks 17. Go to 6 Listing 1: Scheduler Sequence of Operation // check the time slot availability Time_slot = next_schedule (list of resources, current task resources) if (time slot > ) { // calculation of slack at time slot if (first_time_scheduled(current tasks resource)) { available_slack =calculate_slack(next_task, slack_available); } /* find any time slot with slack time greater than AL time slot = calculate slack (next_task, current task resources); // directly execute the task

10 execute(next_task); } In the second level of scheduling tasks heuristic is used to calculate tasks expire time to maintain the quality of service. This inherently identifies the essor(s) release time for the set of processes and their corresponding tasks for each channel. The second level scheduler uses this information to calculate the essors idle time and updates resource utilization table. Heuristic algorithm as second level scheduling policy is not enforced by the software framework followed but rather recommended for media applications where tasks heuristics are instrumental in determining quality of service. Rate Monotonic and Delayed Rate Monotonic are also evaluated as second level scheduler for media application. Nonetheless, whatever scheduler may it be for a given application, it has to be designed as inner loop running iteratively as long as a channel comprising of processes and set of tasks remain active. This scheduler is structured in the following steps in Listing 2: 1. At the arrival of new task the second-level scheduler is called by the first level scheduler indicating the time slot on which the task is scheduled along with its deadline. In the absence of new task, second level scheduler is called at the start of every time slot 2. After every iteration, the second level scheduler checks if any of the running tasks have expired. If so, these tasks are deleted from the queue to make room for new tasks. 3. In every iteration, second level scheduler maintains and updates the resource utilization history and idle time of the essors

11 4. At the end of the slack for current time slot, the second level scheduler releases control to the first level scheduler to add any new tasks, if any or perform any other maintenance related activity. Listing 2: Scheduler Structure Simulation Environment and Performance Curves A graphical simulation utility is designed for performing simulations and analyzing various scheduling techniques for different media applications as shown in Figure

12 Figure 3: Simulation Environment for Software Scheduler Performance Evaluation User may define essor characteristics, memory bandwidth and speed, number of essors in the matrix. To provide more flexibility in testing algorithms for different applications, application characteristics can also be defined in terms of number of channels, processes per channel and tasks per channel along with periodicity. The simulator uses

13 normal distribution to generate the set of tasks, processes and channels at different interval and uses the presented software scheduling framework. Monty Carlo algorithm is used to generate the repeated data for analysis and to create the performance curves. Annexure A contains the source code for the framework and scheduler. Using the developed software framework a clustering heuristic scheduling algorithm for periodic and deterministic tasks is implemented for the example VoIP media gateway application covered in Chapter Six. The scheduler receives different requests from toplevel application when a new channel is opened or closed or when channel characteristics dynamically change. The scheduler receives these requests with a variable probability distribution over time and it attempts to increase the resource utilization, minimize the program code fetch time overhead by clustering similar tasks and reduce the power consumption across the system by attempting to keep as many essors idle when maximum possible channels are not scheduled. Figure 4 Demonstrates the performance of the deployed framework and two level scheduling algorithm on media application with 2 channels scheduled on a set of six heterogeneous processors. As shown, essors utilization is incrementally increasing sequentially. As the number of channels, their corresponding processes and tasks increase a new essor is brought to life. As desired, when the same set of channels are scheduled on multiple larger set of essors, only one Array is used and rest of the Arrays remained inactive to minimize the power consumption

14 1 Grid essor 9 Grid essor 1 8 Grid essor 2 # of Active esses # of Active esses # of Active esses x x x Grid essor 3 35 Grid essor 4 14 Grid essor # of Active esses # of Active esses # of Active esses x x x 1-3 Figure 4: Performance of Heuristic Scheduler Running as Second Level Scheduler with Fixed-Priority Preemptive Running as First Level Scheduler in Media Application To further analyze the performance of software framework on other media application, model Video on Demand Server, covered in Chapter Six, was developed with multiple Texas Instruments DSP models and Spartan FPGA. Performance of software framework and multilevel scheduling policy was analyzed where variant of Rate Monotonic Algorithm were implemented as second level algorithm proceeded by fixed-priority preemptive algorithm. Enhancement in essor utilization and reduction is program code fetch overhead is achieved as shown in Figure

15 5 Grid essor 5 Grid essor 1 5 Grid essor 2 # of esses Scheduled # of essed Scheduled # of esses Scheduled Grid essor 3 5 Grid essor 4 5 Grid essor 5 # of esses Scheduled # of esses Scheduled # of esses Scheduled Figure 5: Performance of RMA with 1 channels scheduled simultaneously in Video on Demand Application. Holes show the essor Idle time due to context switch overhead - 4 -

16 5 Grid essor 5 Grid essor 1 5 Grid essor 2 # of esses Scheduled # of esses Scheduled # of esses Scheduled Grid essor 3 5 Grid essor 4 5 Grid essor 5 # of esses Scheduled # of esses Scheduled # of esses Scheduled Figure 6: Performance of RMA Enhances in Video on Demand Application with Fixed-Priority Preemptive as First Level Scheduler: Similar tasks are better stacked together offering reduced program code fetch overhead Implementation and Interfacing of Scheduler with Hardware Part of RTOS Information on the applications selected by the user generates insight for the breakdown of processes into tasks. The Scheduler issues specialized instructions for the Switch for a given channel at different time slots. Scheduling of tasks requires the maintenance of the order of processing to be carried out on the input sample of signals. The sequence information is part of the instruction that are managed by/executed by/dispatched to the hardware RTOS. The hardware RTOS collects system performance parameters like current execution time, completion and time analysis of the tasks etc and relay this information to

17 the Scheduler. The Scheduler responsibly allocates time slots to the tasks and subtasks after calculating/checking time required by the service requested by the user. It is imperative to keep track of the service completion with respect to essors in order to manage efficient utilization of program code. The Scheduler schedules an instruction, which commands Switch to run a process comprising of multiple tasks on the essor(s). A process may run on a single essor or ping-pong between different essors until the job is completed, some of the instruction patterns generated by the Scheduler for set of twelve essors placed in a matrix are shown in the Figure 7. Software RTOS, Scheduler H ardw are R TO S, Sw itch ess 1 ess 2 ess 3 Three Independent esses scheduled by the Scheduler running different tasks on a set of essors Figure 7: Instruction scheduling & task flow on a set of twelve essors