Feedback-Based Scheduling: a Toolbox Approach Calton Pu
Dept. Computer Science and Eng. Oregon Graduate Institute Beaverton, OR 97006-1999
[email protected]
Robert M. Fuhrer
Department of Computer Science Columbia University New York, NY 10027
1 Background and Introduction Fine-grain scheduling based on software feedback [3] was introduced in the Synthesis operating system [4, 2] to solve two problems: the dependency between jobs in a pipeline and the low-latency requirements of multimedia type applications. The performance level achieved and the adaptiveness of applications running on Synthesis demonstrated the success of ne-grain scheduling based on software feedback. However, the Synthesis implementation of software feedback is specialized for that particular architecture and a particular application (pipelined process scheduling). Consequently, despite the proven success of ne-grain scheduling, it is not easy to port it to another operating system or to apply its lessons elsewhere, even within Synthesis. To address the problems of portability and extensibility of software feedback scheduling mechanisms, we have taken a toolbox approach in our current research. Instead of creating a specialized solution for each particular scheduling problem, we are developing a toolbox of standard, relatively simple components with well-de ned performance and functionality characteristics. The goal is the ability to quickly implement sophisticated software feedback mechanisms by composing these basic toolbox components. The intended applications are primarily in the adaptive scheduling needed in multimedia and real-time domains, especially when input/output operations introduce a large variance in job completion time. The rest of this position paper is organized as follows. Section 2 contains a summary of the basic concepts of software feedback. Section 3 then describes a concrete example using our toolbox approach. Section 5 concludes the paper by qualitatively evaluating this approach and outlining our current research e orts.
2 Software Feedback By software feedback mechanism we mean a software implementation of feedback mechanisms similar to phase-locked loops used in control systems. An example of phase-locked loop is the FM radio receiver, which uses feedback to \track" frequency modulations in the radio broadcast. The goal of a feedback system is to adjust an output sequence according to the observation of input, essentially
predicting the immediate future based on observations of the recent past. If the input signals are within the range accepted by the feedback mechanism, the prediction is guaranteed to be within a bounded distance of the real value. There are three main components in a software feedback mechanism, the meter/counter, the lter, and output generator. The meter captures the observation of the input and compares it to the actually generated output, measuring the error. The lter remembers the recent past, takes into account the current error, and produces the directives for the next step, e.g., in terms of \go faster/slower". This information is then used by the application-speci c output generator to change the system behavior. In software feedback scheduling, these generic components correspond to speci c system modules. The input comes from the progress made by each thread or process. The meter/counter is coupled to speci c events of interest that tell the system whether the current scheduling parameters are achieving the desired e ect. For example, in real-time scheduling the meter watches the progress of a job to see whether it will beat the deadline. Another example is the data movement pipeline in multimedia applications, where the meter watches the queue length at each stage to see whether data is owing smoothly to achieve the maximum bandwidth. The lter forms the heart of a software feedback mechanism. Control systems have developed a large number of lters with well understood properties. For example, a low pass lter accumulates the recent past to eliminate rapid transient changes in the input. Filter is a selective memory that identi es the trend embedded in the input to pass this information to the output generator. A useful toolbox for software feedback should contain a number of basic lters. Each lter should have well-de ned input range (that it can handle), reaction time (how long it takes for a change in input to be re ected in the output), and error bounds (the maximum error for the input range over all time). The toolbox will also include methods and software for composition of basic lters. The output generator is application speci c. However, the toolbox should contain some standard \glues" or translation routines that can connect simple or composite lters to the output generators. Our approach is to de ne an abstract interface to software feedback mechanisms. This interface includes input to lters described as events and output from lters described in terms of \faster for faster output or \slower for slower output." Application output generators will use this standard command to take appropriate action.
3 The Toolbox Approach We are currently developing a toolbox that includes a variety of lters, lter development tools, and lter testing tools based on simulation. Some of the basic lters are straightforward implementations of hardware lters in control systems. Low pass, derivative, and integrator lters are good examples. One limitation of these control system lters is their assumption of linear system behavior. As long as input variations remain linear these lters suce. However, there are situations in operating system scheduling where variations are not necessarily linear. This is of particular concern, for 2
example, when a real-time system approaches CPU saturation. Therefore, we need to develop more specialized lters to handle these non-linear situations. The rules of composition for these non-linear lters are an active area of research. The main lter design tool is an interactive lter speci cation and generation program. It supports the description of lters in a relatively abstract speci cation language. Currently, it takes a generic lter, parameters that limit the input range, and generates the lter to be used in the simulation studies. The development tools run on Apple Macintosh, but the lters are implemented in C for portability reasons. We have been using the CSIM simulation package, distributed by MCC, to validate the performance of basic lters and evaluate the behavior of composite lters.
4 An Example In our previous paper on Fine-Grain Scheduling [3] we have describe an example application where feedback-based scheduling can solve a serious drawback of Unix adaptive scheduling. The problem arises in a pipeline where adjacent stages consume CPU at very di erent rates. Since Unix assumes all processes are independent of each other, congestion would form in front of the stage consuming more CPU, which would get low priority. Similarly, a stage consuming less CPU than the previous would have high priority but stay idle. In a multimedia application, where low latency and high bandwidth are both important, a smooth ow of data through the pipeline would best use the resources of the system, since each stage will be running at just the right speed, without idling or congestion. In the Unix scenario, data ow slows down at the CPU-intensive stage, so the entire pipeline runs at the speed of the lowest priority stage. To solve this problem with ne-grain adaptive scheduling, we adjust the process priority according to the length of its input queue. Each time a queue over ows, the producer is too fast and consumer too slow. We reduce the time slice of the producer and increase the time slice of the consumer. Each time a queue becomes empty, we take the opposite action, reducing the consumer's time slice and increasing the producer's. This has been implemented in Synthesis using specialized lters generated at run-time [3, 4]. We have been using this example application to validate some of the lters in our toolbox development. Not surprisingly, we are starting with linear lters and their composition, which have well known theoretical underpinning. Once we have the linear lters then we will start the experimentation with the non-linear lters. The pipeline example is a simulaton of a data pipeline of N stages connects a linear arrangement of N +1 processes by intervening nite-capacity queues. Process i reads an element from queue i and then writes to queue i + 1; process 0 only produces, while process N only consumes. Each process has a distinct CPU quantum allotted it; time slices are given in round-robin fashion. Observations of relative rates of production and consumption are used to manipulate the quanta so as to equalize the e ective data ow rates. When making adjustments, we rst calculate the rate of consumption/production, where dP 3
and dG are the number of gets and puts (into a queue of xed length, 10 in this example). [i]=cpu[i] Rate[i] = dG[idP + 1]=cpu[i + 1] The observed rate ratios are ltered by a Chebyshev low-pass lter with two parameters: xed cut-o frequency and decibels of attenuation. The low-pass lter protects the feedback from overreacting to sudden changes in CPU consumption (a time interval chosen as a perturbation around a central value). At each iteration, the new quantum is calculated along the pipeline. Each stage adjusts its quantum by the Rate, which remembers the data ow ratio. quantum[0] = PN Q1 i 1 + i=1 ( j =1 Rate1 [j ] )
quantum[i ? 1] quantum[i] = LowPass (RateRatio[i])
Figure 1 shows the resulting CPU allocation of two stages in a pipeline of three stages, with average CPU consumption of relative proprotions 2 : 3 : 1. The vertical axis shows the CPU allocation to a stage as a fraction of the total CPU allocated to the entire pipeline. The horizontal axis represents the time, in units of a queue element owing through the pipeline. On the left, we see the second stage rising from the initial one-third to a stable one-half, and the third stage dropping from the initial one-third to a stable one-sixth. The low-pass lter has a characteristic \hesitation" at the beginning of about 30 steps. A validation run that does not use the low-pass lter shows no stabilization.
5 Evaluation and Current Research Compared to the previous Synthesis work [3], our toolbox approach carries higher overhead, since the lters are less specialized. In compensation, the toolbox brings much more exibility and a better understanding of the components. Speci cally, the basic lters have well de ned \input range" (the variation in the input signal) and performance characteristics (both the convergence rates and error bounds). Our current research is focused on three directions:
The development of the toolbox for multimedia and real-time applications. This is empirical and experimental.
The study of non-linear lters and their composability based on experimental work above. The dynamic optimization of software feedback mechanisms in the toolbox using incremenal specialization [1].
4
Figure 1: Example Convergence in a Pipeline The development of the linear part of the toolbox is guided by previous knowledge from control systems. The development of the non-linear part of the toolbox will rely on existing results as much as possible, as long as they are applicable. We expect to use the toolbox as an experimental vehicle to explore (and reduce) the complexity of non-linear behavior in our particular situation. Finally, we hope to use more general and powerful dynamic optimization techniques currently under development at OGI to eliminate the overhead introduced by the toolbox.
References [1] C. Consel, C. Pu, and J. Walpole. Incremental partial evaluation: The key to high performance, modularity and portability in operating systems. In ACM Symposium on Partial Evaluation and Semantics-Based Program Manipulation, Copenhagen, 1993. To appear. [2] H. Massalin and C. Pu. Threads and input/output in the Synthesis kernel. In Proceedings of the Twelfth Symposium on Operating Systems Principles, pages 191{201, Arizona, December 1989. [3] H. Massalin and C. Pu. Fine-grain adaptive scheduling using feedback. Computing Systems, 3(1):139{173, Winter 1990. Special Issue on selected papers from the Workshop on Experiences in Building Distributed Systems, Florida, October 1989. [4] C. Pu, H. Massalin, and J. Ioannidis. The Synthesis kernel. Computing Systems, 1(1):11{32, Winter 1988.
5
