There are two key concepts in the scheduler – energy credits and run queues. The energy-credit based scheduler gives energy credits to tasks according to the time percent-age generated by Algorithm 1. The amount of the energy credit of a task j on a core p is
credits to tasks, the scheduler repeatedly selects a task to run on a core when the core is ready. A running task consumes a credit per unit of time. The goal is to schedule tasks so that every task uses up all its credits for this time period, thus the throughput is met.
Each core maintains a run queue to manage tasks. A task will only exist in the run queue of one core. This ensures that a task will not run on two cores simultaneously.
In addition, a task can only appear in the queue of a core where it still has credits. The scheduler will schedule a new task to run when the current running task yields the core voluntarily (e.g., due to I/O), or uses up all its credits on that core. Then the scheduler se-lects the next task from the run queue according to high, medium, and low priority defined below. Tasks with the same priority run in a First-In-First-Out (FIFO) order. Algorithm 2 shows the pseudo code of the energy-credit scheduler.
High priority A task is a split task if the task has credits on more than one core. A split task should have a high priority to run, otherwise it would run late in this core, and even later in the other cores in which the task also has credits. As a result the task may not meet its throughput.
Median priority A non-split tasks with available credits will have median priority.
Low priority A task has a low priority in a core if it is not in the run queue of this core, but does have credit on this core.
Migrating tasks frequently between cores incurs significant overheads, so the energy-credit scheduler only migrates task under two conditions. First, if a core is ready but its run queue is empty, the scheduler will search for a task with credits on this core from the run queues of other cores. If such a task is found, the scheduler migrates the task to this core. This is the standard task stealing technique in the literature [4].
Second, if a task uses up its credits on a core, the schedule will migrate it to a core that it still has credits. This is called out-of-credit migration. The task will join the run queue where it still has credit. If no such core can be found, then the task must have met its throughput, and will wait for its execution in the next time period.
Algorithm 2 Energy-credit Based Scheduler
1: for each time interval do
2: Generates a schedule by algorithm 1.
3: for every core do
4: Set the operating frequency according to the schedule.
5: end for
6: while core p has tasks. do
7: repeat
8: Executes the workload of a throughput guaranteed task and consumes the cor-responding credits.
9: until The core becomes “available”.
10: if The task being executed consumes all the credit on this core. then
11: Migrate the task to another core according to its credit.
12: else
13: Move the task to the end of the run queue.
14: end if
15: Pick the next task from the run queue for execution.
16: if No executable task in the run queue. then
17: Steal tasks from the other cores.
18: end if
19: end while
20: end for
It is essential to reduce the overhead of out-of-credit migration. From the analysis of Algorithm 1 it is easy to see that Algorithm 1 will assign a task to at most two cores. We observe, also guaranteed by the analysis of Algorithm 1, only up to two entries in the same row are non-zero. As a result, the scheduler only needs to check the other non-zero entry, instead of the entire row, while deciding which core the task should migrate to during out-of-credit migration.
The fact that Algorithm 1 will assign a task to at most two cores also helps reduce the overheads of task stealing. It is easy to see that there will be at most two partial tasks assigned to a core – one from the previous round and one that continues to the next round.
Consequently, if a run queue is out of tasks, that means all the tasks that were completely assigned to this core have finished, so the core only needs to steal from at most two cores that the partial tasks were also assigned. This helps reduce the effort in locating tasks to steal.
Algorithm 1. Each row indicates the credits a task has on every core.
Table 4.1: An example of energy credits each task receives on each core.
Core1 Core2 Core3 Core4
T ask1 90 0 0 0
T ask2 10 70 0 0
T ask3 0 30 40 0
T ask4 0 0 50 0
T ask5 0 0 10 30
Chapter 5
Implementation
In this chapter, we describe the implementation of energy-credit based scheduler. This scheduler add a new throughput guaranteed task scheduling. We will describe the execu-tion flow of task in this scheduling class.
5.1 Throughput Guaranteed Task Scheduling Class
We propose to add a new throughput Guaranteed Task Scheduling Class. The goal of this scheduling class is to maintain the throughput of tasks and achieves energy efficiency for tasks in this class. The scheduler will provides a throughput guaranteed task the CPU resources that the task needs.
The priority of the throughput guaranteed task scheduling class is between stop-task class and deadline scheduling class. A throughput guaranteed task is no more critical than the stop-tasks, which seriously influence the stability of the system. On the other hand, the deadline tasks only need to meet their deadlines, but the throughput guaranteed task need meet their expected throughput in every time period. As a result, the deadline task is no more critical than the throughput guaranteed tasks.
Power Manager
Figure 5.1: Execution flow of Throughput Guaranteed Task Scheduling Class for Asym-metric Multi-core Processors