Conventional Unix/Linux systems are based on time-sharing schedulers that do ... With the new soft real-time scheduler, users can assign a specified execution ...
A Loadable Variable-Rate Execution Schedule Xin Liu and Steve Goddard Computer Science & Engineering University of Nebraska—Lincoln Lincoln, NE 68588-0115, USA {lxin,goddard}@cse.unl.edu Abstract Conventional Unix/Linux systems are based on time-sharing schedulers that do not adequately support applications with QoS requirements, such as multimedia applications. In this project, we built a loadable Variable-Rate Execution scheduler to provide QoS to applications. The scheduler is implemented as a Linux loadable module, which can be dynamically loaded into the kernel to change the Linux scheduler. With the new soft real-time scheduler, users can assign a specified execution rate to any application, which is more precise than either the best-effort time-sharing algorithms or the all-or-nothing POSIX real-time priorities. In addition, users can dynamically adjust the execution rate during runtime. Since different applications may have different execution rates, it is infeasible to predict the execution rate in general. Instead, we provide an interface for users to associate each variable rate task with a rate controller that automatically adjusts the task’s execution rate. We also provide a default rate controller for legacy applications. The default rate controller assumes that the application can suspend itself when it is allocated a higher execution rate than its need. If the suspension time is greater than a upper threshold, the rate controller slows down the execution rate; if the suspension time is less than a lower threshold, it speeds up the execution.
1
Introduction
rate of a multimedia application. For example, a program runs faster on an 800MHz P3 processor than on a 400MHz P2 processor. Moreover, the execution pattern of a multimedia application on any given computer is difficult to predict. The decoding time of each MPEG frame can be variable, depending on factors such as frame type, length and so on [3]. Our schema is: a multimedia application is assigned an initial bandwidth and associated with a rate controller to dynamically adjust the execution rate. Since different applications can have different execution patterns, it is difficult to provide a universal rate controller for all applications. Thus, the construction of specific rate controllers is beyond the scope of this work. Instead, we focus on the rate adjustment mechanism and the framework in this work. However, a simple rate controller is still defined as a default rate controller. The default rate controller monitors the actual execution rate of an application. If the actual execution rate does not match the reserved bandwidth, the controller can adjust the reserved execution rate based on the difference. Since time-sharing systems dominate today’s popular operating systems, millions of applications
Conventional Unix/Linux systems are built upon time-sharing schedulers. In recent years, many new applications, typically multimedia applications, emerged with QoS requirements, which need new scheduling policies. Much work has been done on QoS-supported CPU scheduling. Theoretical models like Rate-Based Execution (RBE) [12] and Constant Bandwidth Server (CBS) [1] were proposed; schedulers, such as BERT [4] and SMART [17], were developed. Most models, such as CBS and RBE, follow the bandwidth reservation schema such that an application can reserve specific processor capacity to keep a guaranteed execution rate. It would seem to be a good choice for multimedia applications, but it lacks a rate adjustment mechanism. In practice, multimedia applications can dynamically change their execution rates, and therefore change their resource requirements. We believe a rate adjustment mechanism is as important as a bandwidth reservation mechanism. There are too many factors to easily determine the 1
any modification. In addition, the rate controller component provides the interface for users to customize their specific rate controllers. This work presents both theoretical and experimental results. The scheduler is implemented as a loadable Linux module. Users can either use the original Linux scheduler or use our scheduler by loading the kernel module. Only a small modification is made to the Linux kernel. The programming interface is simple and concise. The rest of this paper is organized as follows. Section 2 discusses related work. Section 3 introduces the processing model assumed in this work and gives an overview on the programming interface. Section 4 presents the experiments and results. We conclude with a summary and discussion of future work in Section 5.
have been built on time-sharing systems. We call those applications legacy applications. Many legacy applications, especially multimedia applications, have QoS demands; their jobs have to be done in time. However, conventional Unix/Linux systems do not provide QoS support. Considering millions of legacy applications, it is actually infeasible to rebuild the legacy applications upon a completely new platform. A likely solution is to support legacy multimedia applications at the binary level such as the CBS algorithm does. This work enhanced the Linux kernel to dynamically load user-customized schedulers, which separates specific scheduling policies from the scheduling mechanism. The variable rate execution model, a specific scheduler in this work, is an extension of the Rate-Based Execution (RBE) model [12]. The RBE model schedules tasks at an average rate. While the frequency of job releases may be variable, job processing is at a constant rate. This prevents bursts from saturating processor capacity. The RBE model is close to meeting the requirements of multimedia applications, but it does not support non-real-time tasks and it is also unable to dynamically adjust the execution rate. An enhanced RBE model with aperiodic request support was proposed in [10]. It is extended to the variable rate execution task model to fit the requirements of multimedia applications. Although the task model of this work is a little different from the model in [10], the techniques used to adjust the rate are identical. Our model supports both variable rate tasks and non-real-time tasks. Variable rate tasks reserve a specific execution rate and dynamically adjust the rate. Non-real-time tasks proportionally share the remaining processor capacity as if they were scheduled by a time-sharing system. The two task types are modeled at the thread level. We use the term thread to refer to the minimum scheduling unit of OS kernels. In Linux, all processes are implemented as threads. Thus, the kernel supports two types of threads:
2
Related Work
In practice many QoS-supported OSs and multimedia OSs, such as QLinux, BERT and SMART, came from the perspective of proportional-sharing scheduling, which employs fair queuing and Earliest Deadline First(EDF) as their fundamental scheduling mechanism. Weighted Fair Queueing (WFQ) [6] (also known as packet-by-packet generalized processor sharing (GPS)) is a well-known proportional scheduling algorithm from the networking literature. The WFQ scheduler associates a weight to each connection session; all the connection sessions share the router’s bandwidth in proportion to their weights. The WFQ scheduler creates a packet queue for each session. Packets are selected FIFO within the queue. Each queue is parameterized by a static weight and a dynamic expected finish time. When the first packet in a queue departs, the expected finish time f ti is updated as f ti = max(ri , f ti ) + Bli where Bi is the bandwidth reserved for session i, ri is the arrival time of the next packet, f ti is the finish time, l is the length of next packet. Worst-case Fair Weighted Fair Queuing (W F 2 Q) [5] is an extension of WFQ that prevents a task from getting executed faster than expected in a perfect fair share scheduler. Two recent multimedia schedulers are built on WFQ, SMART [17] and BERT [4]. The SMART scheduler [17] separates urgency from importance. A task’s importance is measured by a value-tuple, which consists of two components: priority and biased virtual finishing time (BVFT). Priority is a static quantity; BVFT is a dynamic quantity used to measure the degree to which each task has been allocated its proportional share of the resource. Priority
• Variable rate threads are initially assigned an execution rate, and the rate can be dynamically adjusted at runtime by either a rate controller or users’ commands; • Non-real-time threads share the remaining processor capacity in proportion to their weights; Both variable rate threads and non-real-time threads are consistent with legacy applications. That is, legacy applications can run as either variable rate threads or non-real-time threads without any modification. The major advantage of our work is that it provides QoS support to legacy applications without 2
is treated as the major component. If the task with highest priority is a conventional task, it is run; otherwise, the scheduler tries to satisfy as many deadlines as possible on the condition that deadlines of higher priority tasks are made. BERT [4] is essentially an implementation of W F 2 Q plus a cycle stealing mechanism. While W F 2 Q provides proportional sharing, the cycle stealing mechanism provides a flexible way for urgent tasks to meet their deadlines when their demands exceed their shares. The proportional scheduler assumes the system is not overloaded. If the system is overloaded, then the importance of processes to the user should be used to resolve conflicts. QLinux [11, 21] employs the Hierarchical Starttime Fair Queuing (H-SFQ) algorithm, which is similar to WFQ. Rather than an expected finish time in WFQ, each job is assigned a start tag in SFQ and the start tag is computed in a similar manner as the virtual finish time. The Start-time Fair Queuing scheduler always chooses the job with the earliest start tag. QLinux partitions all threads into several groups; each group reserves a bandwidth in proportion to its weight. Each group also has a scheduler that schedules the group members in proportion to their weights. Instead of employing the two-level hierarchy, the Earliest Eligible Virtual Deadline First (EEVDF) [20] algorithm puts all aperiodic jobs into the same queue and assigns a deadline for each job. According to task weight wi , release time ti0 and execution time rk , the virtual eligible time ve and virtual deadline vd of a task is computed using equations presented in [20] and summarized as follows: ve1 = V (ti0 ); vdk = vek +
parameters: Cs and Ts ; Cs time units are reserved in a period of Ts time units. The server’s deadline is updated with the following equation: dk = max(tk , dk−1 ) + ck /Us where dk−1 is the previous deadline, tk is the release time of the k th request, ck is the execution time of the k th request and Us = Cs /Ts is the capacity of the server. CBS severs can also handle aperiodic requests in the same way. Though similar to this work, the CBS algorithm lacks an adaptation mechanism. In fact, the execution environments of multimedia applications are variable and it is difficult to predict and describe the time constraints of legacy multimedia applications [3]. This work extends the RBE model to a variable rate execution model model to support a dynamic task set that includes non-realtime tasks and variable rate tasks. The RBE model schedules tasks at average rates. It does not, however, have an adaptation mechanism. In this work, a rate adjustment mechanism is added to support the adaptive execution of legacy multimedia applications. The rate adjustment mechanism is similar to the processing of aperiodic requests in [10].
3
The Processing Model
This section discusses the processing model. Section 3.1 introduces the loadable scheduler mechanism. Section 3.2 presents the theoretical model of variable rate tasks. Section 3.3 presents the programming interface for the new scheduler. Section 3.4 introduces the concept of rate controllers.
r(k) ; vek+1 = vd(k) . wi
The deadline is inversely proportional to the weight in virtual time, which implies proportional-sharing under an EDF scheduler. In order to reduce jitter, eligible time is introduced to prevent a task from getting executed faster than expected in a perfect fair share model, which is similar to W F 2 Q. The Constant Bandwidth Server [1] algorithm is essentially another variant of WFQ. The CBS algorithm processes multimedia applications at a reserved constant rate which is similar to this work. CBS runs multimedia applications on a CBS server, which is assigned a fixed bandwidth. The execution of a multimedia application is decomposed into a sequence of time slices, called a budget in the CBS server, and each time slice is assigned a deadline which is represented by the deadline of the CBS server. While a server is executing, its budget is reduced until it reaches zero. The server gets replenished when its budget expires. A CBS server has two
3.1
Loadable Schedulers
The loadable scheduler mechanism is implemented by pre-planting several hooks in the original Linux kernel. A data structure (scheduler) is defined as the interface of user-customized schedulers, which is shown in the following code. /* scheduler structure
*/
/* this structure defines the hook table in kernel */ struct scheduler{ struct prio (*sched_goodness) (struct task_struct * p, int this_cpu, struct mm_struct *this_mm); void (*sched_fork) (struct task_struct *task); void (*sched_exit) (struct task_struct *task); void (*sched_sleep)
3
3.2.1
(struct task_struct *task); void (*sched_wakeup) (struct task_struct *task); struct task_struct *(*sched_choose_next) (struct task_struct*, int); void (*sched_nice) (struct task_struct*, int, void*); void (*sched_handle_ticks) (struct task_struct*, unsigned long ); void (*sched_replenish) (struct task_struct*);
The variable rate task model is an extension of of the RBE model [12] which schedules tasks at their average rates. A RBE task is specified by a four-tuple (x, y, d, c) of integer constants. • The pair (x, y) is referred to as the rate specification of a RBE task; x is the maximum number of executions expected to be requested in any interval of length y.
};
In the Linux kernel, the hooks are pre-planted as follows:
• Parameter d is a response time parameter that specifies the maximum desired time between the release of a task instance and the completion of its execution (i.e., d is the relative deadline of the task).
int do_fork(unsigned long clone_flags, unsigned long stack_start, struct pt_regs *regs, unsigned long stack_size) { ... #ifdef LOADABLE_SCHEDULER p->policy=SCHED_EDF; if(p_sched!=NULL) (*p_sched->sched_fork)(p); #endif ... }
• Parameter c is the maximum amount of processor time required for any job of task T to execute to completion on a dedicated processor. A RBE task set is schedulable if there exists a schedule such that the j th release of task Ti at time tij is guaranteed to complete execution by time Di (j), where ( tij + di if 1 ≤ j ≤ xi Di (j) = max(tij + di , Di (j − xi ) + yi ) if j > xi (1)
When a scheduler is loaded, the p sched point is directed to its specific scheduler. Thus, its sched fork function will be invoked when a thread is created by do fork. When the scheduler is removed, it sets the p sched point back to NULL.
3.2
Variable Rate Tasks
The second line of Equation (1) prevents the processor from being saturated by early job releases. See [12] for more details. Since legacy applications are essentially instruction sequences, their executions can only be decomposed into sequential time slices, which is exactly what happens in conventional time-sharing systems. Thus, each time slice is a scheduling unit. To achieve a reserved execution rate, we assign each time slice a deadline. In the enhanced RBE model [10] and this work, we call each time slice a job; in the CBS model, the time slice is represented by the budget of a CBS server [1]. The variable rate tasks are intentionally designed to target legacy multimedia applications. Following the notation of the RBE model, we describe a variable rate task by a four-tuple (1, pi (t), pi (t), ci (t)), which means the task will be allocated 1 time slice of size ci (t) every period of length pi (t). Here, the deadline must be equal to the period. That is, di (t) = pi (t). When a variable rate task (a legacy multimedia application) starts, the scheduler checks the schedulability condition in Section 3.2.3 and registers the task with the system. Then the first time-slice is
Theoretical Model
The theoretical model represents several extensions to the RBE model first proposed in [12] and enhanced to support aperiodic request processing in [10]. In this work, we have added a rate adjustment mechanism to the RBE model. Thus, variable rate tasks reserve an initial execution rate, and the rates can be dynamically changed. Non-real-time tasks are grouped together and scheduled by an aperiodic server which takes the remaining available processor capacity. For readers familiar with [10], there is a major difference introduced here. Instead of modeling each aperiodic task with a variable rate task as in [10], we group all non-real-time tasks into one task, which is executed by an aperiodic server. Within the aperiodic server, non-real-time threads are proportionally scheduled based on their assigned weights. The aperiodic server can employ any proportional-share scheduler. We chose WFQ (Weighted Fair Queuing) [6] for the implementation. The rest of this section presents how each type of task is modeled. Section 3.2.3 gives a schedulability condition for admission control. 4
marked with a deadline by Equation (1) and scheduled by an EDF scheduler. Once a time slice expires, the next time slice is released immediately and marked a deadline with Equation (1). When the variable rate task terminates, it is unregistered from the system. The rate adjustment is implemented by the adjustment of either the pi (t) parameter or the ci (t) parameter. The rate adjustment mechanism is useful in adaptive executions. Suppose a video decoder needs to run 1ms to decode 20 frames at low image quality, it needs 2ms to decode the same number of frames at high image quality. For this case, we only need to adjust its ci (t) parameter from 1ms to 2ms. We can also adjust the execution rate when the same application runs on two different computers. Similar to the aperiodic requests in [10], the variable task is first associated with a processor fraction; then the fraction is mapped into a rate description. Let fi (t) be the fraction allocated to a legacy application Vi . Vi is mapped into a variable rate task by the following equation: ψ(Vi ) : Vi → Tˆi = (1, pi (t), pi (t), ci (t))
the set of variable rate tasks at time t, the fraction of the aperiodic server at time t is defined as follows: X fj (t) Fˆ (t) = 1 − (5) j∈V (t)
Fˆ (t) changes with any of the following cases: • Variable rate tasks enter the system • Variable rate tasks leave the system • Variable rate tasks change their rates Within the aperiodic server, non-real-time tasks are scheduled by a WFQ [6] scheduler as follows. Each non-real-time task is marked with a virtual finish time f t(i); the execution of a non-real-time task is decomposed into a sequence of time slices as the variable rate tasks discussed in Section 3.2.1. The aperiodic server always chooses the task with the earliest virtual finish time. When the running nonreal-time task’s time slice expires, its next time slice is released immediately and its virtual finish time is updated by the following equation: f t(i) = f t(i) +
(2)
where wi is the weight associated with non-real-time task i and C is the virtual processing capacity, which is a constant. The virtual time is updated by the following equation: C∆ v(t + ∆) = v(t) + P wi When a new non-real-time task arrives at time t, its virtual finish time is assigned as follows:
where ci (t) = fi (t). pi (t)
(3)
As we can see from the above equation, there are infinite combinations of ci (t) and pi (t) that satisfy Condition (3). In practice, most multimedia applications have a fixed period. Suppose in a video, people will notice excessive jitter if the rate is less than 15 frames per second. Then 66ms can be used as its period (pi (t)). As long as one variable is determined, the other variable can be computed by Condition (3). fi (t) in Equation (3) is variable, subject to change during adaptation. Suppose the fraction fi (t) changes from fi (t − 1) to fi (t) at time t, the rate of task Vi is recomputed by Equations (2) and (3). Then the next deadline is assigned by Equation (1) with the new rate. Similar to what happens in [10], the current deadline D of Vi needs no adjustment if D = t; if D 6= t, then D needs to be adjusted by the following equation: D0 = t +
3.2.2
Aperiodic Tasks
(D − t) · fi (t − 1) fi (t) Server
&
C wi
f t(i) = v(t) + 3.2.3
C wi
Schedulability Condition
A sufficient schedulabity condition for the enhanced RBE model was given in [10]. The condition is also sufficient for the model in this work. We represent it in a slightly different form in this section. Lemma 3.1 bounds the demand of a variable rate task; Theorem 3.2 gives a schedulability condition. Lemma 3.1. [10] Let Tˆi = ψ(Vi ) represent a variable rate task Vi ∈ V (t). If no job of Tˆi released before time t0 ≥ 0 requires processor time in the interval [t0 , l] to meet a deadline in the interval [t0 , l], then Z l d ([t0 , l]) = (6) ∀l > t0 , dbf fi (t)dt
(4)
Non-real-time
t0
is an upper bound on the processor demand in the interval [t0 , l] created by Tˆi where ψ(Vi ) is defined by Equation (2) and fi (t) is the fraction function of Vi .
The aperiodic server is also a variable rate task that takes the remaining processor capacity. Let V (t) be 5
S∞ Theorem 3.2. [16] Let the task set T = t=0 V (t) be the set of variable rate tasks with di (t) = yi (t), 1 ≤ i ≤ n. Preemptive EDF will succeed in scheduling T if Equation (7) holds where fi (t) is the portion of the CPU capacity allocated to variable rate task Vi at time t. X ∀t, fi (t) ≤ 1 (7)
3.3.2
Variable rate threads are designed for legacy multimedia applications. Variable rate threads are the thread model of variable rate tasks, which reserve an execution rate and change the rate during runtime. The programming model of variable rate threads is consistent with conventional time-sharing systems. Thus, legacy multimedia applications need no modification. Instead, a system interface set execution rate is provided to set the execution rate of a thread. If the thread is a non-real-time thread, then set execution rate will convert it into a variable rate thread.
i∈V (t)
Theorem 3.2 is used as the condition for admission control. When a new variable rate task arrives or an existing variable rate task requests to change its rate, the system will recompute the fraction of the aperiodic server by Equation (5). If the newly computed fraction is less than a threshold, then the scheduler should reject the new task or the rate change request; otherwise, the scheduler accepts the change.
3.3
set_execution_rate(pid, 1, y, y, c);
The above statement sets the execution rate of thread pid to (1, y, y, c) which means pid will run c time units every y time units. Variable rate threads bridge the gap between legacy time-sharing applications and QoS-based applications. A legacy application can switch its thread type between non-real-time thread and variable rate thread through system interfaces set weight and set execution rate. We treat variable rate threads as black boxes; the scheduler does not know any internal implementation details or deadlines. However, we can still estimate the execution rate of a legacy multimedia application by monitoring its execution as we will see in the experiments.
Programming Model
The programming model is implemented at the thread level and consists of two types of threads: non-real-time threads and variable-rate threads. Legacy applications, by default, are supported as non-real-time threads. Legacy multimedia applications can also be converted to variable rate threads with a system interface. 3.3.1
Variable Rate Threads
Non-real-time Threads To summarize, the thread model is shown in Figure 1.
Non-real-time threads are compatible with conventional time-sharing systems at the binary level. Any legacy time-sharing program can run as a non-realtime thread without modification. The f ork system call creates a non-real-time thread by default, as shown with the following code statement.
VR
VR
N
User Level
N
Kernel Level
Run Queue
new_pid=fork();
Proportional Scheduler Aperiodic Server
Similar to time-sharing systems, each non-realtime thread is associated with a weight which indicates its significance related to other non-real-time threads. Consistent with the Linux scheduler, each non-real-time thread is assigned a weight of 20 by default. A system interface set weight is used to adjust a non-real-time thread’s weight. The following code changes the weight of thread pid to 40.
EDF Scheduler VR: variable rate thread
N: Non-real-time thread
FIGURE 1: All threads, including variable rate threads and non-real-time threads, are put in the ready queue in the kernel. While variable rate threads are directly scheduled by the underlying EDF scheduler, all non-real-time threads are first scheduled by the aperiodic server and the aperiodic server is scheduled by the EDF scheduler.
set_weight(pid, 40);
This is similar to the nice interface defined in POSIX. 6
3.4
Rate Controller
struct rate_controller{ unsigned long period; void (*control)(struct task_struct *p_task); }
So far, we have introduced variable rate tasks. Thus, users can dynamically change the execution rate at runtime. But, we cannot expect users to make the adjustments all by hand since the adjustments might be too frequent and the rules might be too complicated. We introduce the component rate controller to automatically accomplish the rate adjustments. The rate controller monitors the execution and automatically adjusts the rate based on some predefined rules. We believe it is infeasible to construct a generalpurpose rate controller. In practice, different applications can have different execution patterns. Thus, we provide an interface for users to implement customized rate controllers. Each variable task can have its own rate controller adjusting its execution rate, as shown in Figure 2.
Rate Controller
Thread
Rate Controller
Thread
where period is the period that the function control is invoked. The interface to play with rate controllers are shown below. • add controller(char *name, struct rate ctlr *ctlr) adds a rate controller ctlr into the system; • rm controller(struct rate ctlr *ctlr) removes a rate controller ctlr from the system; • set controller(pid t pid, char *controller, unsigned long period) assigns a rate controller ctlr to a thread pid.
Rate Controller
4
Thread
Evaluation
The programming and task models have been implemented in Linux and evaluated with non-real-time and legacy multimedia applications. The scheduler is implemented as a loadable Linux module on Redhat 7.2. Only a small modification is made to the Linux kernel. Our experiments focus on three aspects: QoS support, the variable rate mechanism and the default rate controller. The experiments were done on a PC with an Athlon Thunderbird 1GHz processor. We selected MPlayer as the legacy multimedia application. The first experiment is to evaluate the QoS support. We ran MPlayer on both the original Linux scheduler and our new scheduler. In our scheduler, the execution rate of MPlayer is set to (1, 10, 10, 1). That is, the MPlayer shall receive 1 time tick (10 microseconds) every 10 time ticks, which is actually faster than its required execution rate. As shown in Figure 3, the actual execution rate of MPlayer is close to (1, 12, 12, 1). Every 15 seconds, we check the execution time of MPlayer and create 20 non-realtime processes which do nothing but execute infinite loops. As we can see in Figure 3, the original Linux scheduler provides no QoS guarantee; the execution rate (the slope) decreases when new processes are created. But our model provides constant service quality when new processes are created.
Scheduler
FIGURE 2: Rate Controller However, we do provide a simple rate controller for all legacy applications. Our strategy is based on a reasonable assumption. We assume a legacy application will suspend itself when it runs faster than its need. Take a video decoder as an example, the decoder shall decode 30 frames in a second. If the decoder decodes 30 frames in the middle of a second, then it will suspend itself for the rest of the second. Our strategy is, • periodically check the execution time (e). Suppose we check the execution time at time t (e(t)), then we check the execution time after p time (e(t + p)). • compare the execution time(∆e = e(t + p) − e(t)) with the expected execution time(c). Of course, ∆e ≤ c if there are non-real-time tasks that fill the remaining processor capacity. • set both lower and upper thresholds (δl and δu )for the difference (c − ∆e). If c−∆e ≤ δl , c then accelerate the execution rate. If c−∆e ≥ c δu , then decelerate the execution rate. Otherwise, keep the execution rate. A rate controller is currently defined as follows: 7
14
16
14
12
12
10 Execution time (second)
Execution time (second)
Original Linux New scheduler
10
8
6
8
6
4 4 2 2 0
0 0
20
40
60
80
100
120
140
0
160
20
40
60
100
120
140
160
180
FIGURE 4: The actual execution rate increases when we increase its rate specification, but falls around time 155 when the rate specification is greater than the actual job release rate.
FIGURE 3: The execution rate in the original Linux scheduler decreases as the system load increases while the new scheduler maintains a constant execution rate. The actual execution rate in our scheduler is close to (1, 12, 12, 1), which is slower than the assigned rate.
An interesting thing in Figure 4 is the rate change around time 155 where we did not adjust the rate. It appears that rate (1, 10, 10, 2) is faster than the real rate of job releases. When the execution rate was changed to (1, 10, 10, 2) at time 120, MPlayer had to finish the pending jobs accumulated through the interval [0, 120]. Thus, MPlayer executed at its full rate (1, 10, 10, 2) in the interval [120, 155]. When the accumulated pending jobs were finished, its execution rate dropped to the real rate of job releases.
The second experiment is on the execution pattern of legacy multimedia applications under the rate adjustment mechanism. We changed the execution rate of MPlayer at selected points and checked the execution time of MPlayer every 3 seconds. Table 1 shows the execution rate adjustments and the times when they are made. We use different time units for the two columns, which might be confusing at first. We use a second as the time unit in the Time column, while in the Rate column we use a tick (which is 10ms in Linux by default) as the time unit. For example, the second entry in Table 1 means we change the rate to 1 tick every 30 ticks at the 30th second.
20
15 Execution time (second)
Time(in seconds) 0 30 60 90 120
80
Real time (second)
Real time (second)
Rate (x,y,d,c) (in 10ms ticks) (1,50,50,1) (1,30,30,1) (1,20,20,1) (1,10,10,1) (1,10,10,2)
10
5
0
TABLE 1: Rate adjustment.
0
20
40
60
80 100 Real time (second)
120
140
160
FIGURE 5: The default rate controller detected contention at time 45 and accelerated the execution rate.
The execution time of MPlayer with rate adjustment is shown in Figure 4. To highlight the execution rate of MPlayer, the null program execution is not included in Figure 4. We can verify that the rate changes are consistent with our adjustments shown in Table 1.
The third experiment is on the default rate controller. We initially set MPlayer to run at a low rate ((1, 20, 20, 1)). The actual execution rate is a little bit slower than the assigned rate because of the 8
time tasks,” Technical Report TR-602-99, Department of Computer Science, Princeton University, Mar, 1999.
roundoff in the implementation. Then we attached the default rate controller to MPlayer at time 45. As we can see from Figure 5, the default controller immediately detected the contention and accelerated the execution rate. When all pending jobs were finished, the execution rate dropped to the regular rate. The results looks similar to the second experiment, but the rate adjustment was done automatically by the controller.
5
[5] Bennett, J., Zhang, H., “WF2Q: Worst-case Fair Weighted Fair Queueing,” IEEE INFOCOM ’96, San Francisco, CA, Mar. 1996, pp. 120-128. [6] Demers, A., Keshav, S., and Shenker, S., “Analysis and simulation of a fair queuing algorithm,” Proceedings of the SIGCOMM ’89 Symposium, Sep. 1989, pp. 112.
Conclusion
[7] Deng, Z., Liu, J.W.S., Sun, J., “A Scheme For Scheduling Hard Real-Time Applications in Open System Environment,” In Proceedings of the Ninth Euromicro Workshop on Real-Time System, Toledo, Spain, June 1997, pp. 191-199.
This work enhanced the Linux kernel to dynamically load user-customized schedulers. A variable rate execution scheduler is designed to support legacy applications. The model consists of two types of tasks. Non-real-time tasks are consistent with time-sharing systems whose importance is indicated by a relative weight; variable rate tasks run at a variable rate which is adjusted for adaptation during runtime. A schedulability condition is given for admission control. Variable rate threads are designed such that users can control the execution rate without knowing the internal implementation of a legacy application. Each variable rate thread can attach a rate controller to automatically adjust its execution rate. Legacy applications are treated as non-real-time threads by default, but they can be converted to variable rate threads though the system interfaces. The implementation is done on Redhat 7.2. Our experiments show that the real release rate of a multimedia application can be approximated by monitoring the real execution; no information of internal implementation details is required.
[8] Deng, Z., Liu, J.W.S., “Scheduling Real-Time Applications in an Open Environment,” RealTime Systems Journal, vol. 16, no. 2/3, pp.155186, May 1999. [9] Ghazalie, T. M., Baker, T. P., “Aperiodic Servers in Deadline Scheduling Environment”, Real-Time Systems Journal, vol. 9, no. 1, pp. 31-68, 1995. [10] Goddard, S., Liu, X., “Scheduling Aperiodic Requests under Rate-Based Execution model” Proceesings of IEEE Real-Time System Symposium, December 2002, pp. 15-25. [11] Goyal, P., Guo, X. and Vin, H. M., “A hierarchical CPU scheduler for multimedia operating systems”, In Proceedings of the Second Symposium on Operating Systems Design and Implementation (OSDI). USENIX, October 1996. [12] Jeffay, K., Goddard, S., “A Theory of RateBased Execution,” Proceedings of the 20th IEEE Real-Time Systems Symposium, Phoenix, Arizona, December 1999, pp. 304-314.
References [1] Abeni, L., Buttazzo, G., “Integrating Multimedia Appplications in Hard Real-Time Systems,” Proc. IEEE Real-Time Systems Symp., Madrid, Spain, Dec. 1998.
[13] Lehoczky, J.P., Sha, L., and Strosnider, J.K., “Enhanced Aperiodic Responsiveness in Hard Real-Time Environments,” Proceedings of IEEE Real-Time Systems Symposium, pp. 261-270, Dec. 1987.
[2] Baker, T.P., “Stack-Based Scheduling of RealTime Processes,” The Journal of Real-Time Systems 3(1), pp. 67-100, 1991. IEEE Computer Society Press.
[14] Lipari, G., Baruah, S., “Greedy reclamation of unused bandwidth in constant-bandwidth servers”, Proceedings of the EuroMicro Conferences on Real-Time Systems, pp. 193-200, Stockholm, Sweden. June 2000.
[3] Bavier, A., Montz, A., and Peterson, L., “Predicting MPEG execution times,” Proc. of the Joint International Conf. on Measurement and Modelling of Computer Systems, Madison, WI, Jun. 1998, pp. 131-140.
[15] Liu, C., Layland, J., “Scheduling Algorithms for multiprogramming in a Hard-Real-Time Environment,” Journal of the ACM , Vol 30., Jan. 1973, pp. 46-61.
[4] Bavier, A., Peterson, L. and Mosberger D., “BERT: A scheduler for best effort and real9
[16] Liu, X., Goddard, S., “A Variable Rate Execution Model” Technical Report, University of Nebraska - Lincoln, September 2003.
ing,” Proc. of the IEEE Symposium on RealTime Systems, December 1994.
[17] Nieh, J., Lam, M., “The Design, Implementation and Evaluation of SMART: A Scheduler for Multimedia Applications,” Proc. of the 16th ACM Symposium on Operating Systems Principles, Saint-Malˆ o, France, Oct. 1997, pp. 184197.
[20] Stoica, I., Abdel-Wahab, H., Jeffay, K., Baruah, S. K., Gehrke, J. E., Plaxton, C. G., “A Proportional Share Resource Allocation Algorithm for Real-Time, Time-Shared Systems,” Proc. of the IEEE Symposium on Real-Time Systems, Dec. 1996, pp. 288-299.
[18] Sprunt, B., Sha, L., Lehoczky, J.P., “Aperiodic Task Scheduling for Hard Real-time Systems,” Real-Time Systems Journal, vol 1, no. 1, pp. 27-60, 1989.
[21] Sundaram, V., Chandra, A., Goyal, P., Shenoy, P., “Application Performance in the QLinux Multimedia Operating System,” Proceedings of the Eighth ACM Conference on Multimedia, Los Angeles, CA, November 2000, pp. 127-136.
[19] Spuri, M., Buttazzo, G., “Efficient Aperiodic Service Under the Earliest Deadline Schedul-
10
