Modular Real-Time Resource Management in the Rialto Operating System Michael B. Jones, Paul J. Leach, Richard P. Draves, Joseph S. Barrera, III May, 1995 Technical Report MSR-TR-95-16 Microsoft Research Advanced Technology Division Microsoft Corporation One Microsoft Way Redmond, WA 98052 Paper presented at the Fifth Workshop on Hot Topics in Operating Systems (HotOS-V), May, 1995. Modular Real-Time Resource Management in the Rialto Operating System Michael B. Jones, Paul J. Leach, Richard P. Draves, Joseph S. Barrera, III Microsoft Research, Microsoft Corporation One Microsoft Way, Building 9S/1 Redmond, WA 98052 [email protected], [email protected], [email protected], [email protected] Abstract also to distributed applications that make use of remote This paper describes ongoing investigations into resources through remote object invocations. algorithms for modular distributed real-time resource To be usable in a tractable fashion, it is our belief that management. These investigations are being conducted resource management must be modular. By this, we mean in the context of the Rialto operating system – an object- that it should be possible to write and use software based real-time kernel and programming environment components (classes, modules, libraries, etc.) that have currently being developed within Microsoft Research. real-time resource requirements as components of larger Some of the goals of this research include developing real-time modules or programs without having to appropriate real-time programming abstractions to allow understand their implementations in order to reason about multiple independent real-time programs to dynamically their real-time resource requirements. This allows the coexist and share resources on the same hardware traditional benefits of modularity (abstract interfaces, platforms. Use of these abstractions is intended both to information hiding, the ability to reimplement, etc.) to be allow individual applications to reason about their own carried forward into real-time programming. resource requirements and for per-machine system As well as applying to software components, we resource planner applications to reason about and believe that this kind of modularity of resource control resource allocations between potentially requirements must also extend to entire real-time competing applications. The set of resources being applications. This allows a system resource planner managed is dynamically extensible, and may include application to reason about and participate in overall remote resources in distributed environments. The local resource allocations between applications, just as an planner conducts resource negotiations with individual application can reason about its own internal resource applications on behalf of the user, with the goal of requirements. The planner makes resource allocation maximizing the user’s perceived utility of the set of decisions between applications on behalf of the user. running applications with respect to resource allocations 2. The Problem Being Solved for those applications. This paper focuses on one aspect of the real-time 1. The Need for Modular Real-Time programming model provided by and used within the Resource Management Rialto operating system. This aspect is: • One of our major research goals for the Rialto An extensible modular distributed real-time resource- operating system is to investigate programming management scheme with which programs can reason abstractions that make it possible for multiple independent about their own real-time resource needs and real-time applications to dynamically coexist and share negotiate for resource reservations based on those resources on the same hardware platforms. In particular, needs. just as it is possible to today to purchase or write time- 2.1 Research Context sharing applications that successfully coexist with other This research is being conducted in a larger context time-sharing applications, we are researching a real-time of real-time systems work. While not the focus of this software architecture that is intended to make it possible paper, it is nonetheless useful to have an overview of this to purchase or write real-time applications that can larger systems context so as be able to better understand successfully coexist both with other real-time applications our resource management strategy. Other features integral and time-sharing applications. Furthermore, the to the programming model are: techniques we are developing are designed to be • A constraint-based real-time scheduler. Time applicable not just for single-machine applications, but constraints contain a deadline, a time estimate, and an earliest start time. The scheduler notifies the resource utilization, rather than always limiting resource application if a constraint is unlikely to be met, allocations to account for worst-case behavior. providing for proactive load shedding in cases of transient overload. Actual time taken is reported 3. Resource Management Design back to the application, providing the basis for a This section describes our approach to modular real- realistic real-time feedback mechanism. This is a time resource management, giving examples to help simplification of the mechanism described in [Jones clarify how it would be used in practice. 93]. 3.1 Resource Management Abstractions • An object invocation mechanism that propagates a The following abstractions are used by our approach thread’s real-time scheduling constraints to remote to real-time resource management: object invocations, both to remote processes and to • Resource: A limited hardware or software quantity remote machines. (The object invocation mechanism provided by a specific machine. Individual resources is a real-time implementation of the Component might include CPU time, memory, I/O bus Object Model (COM), the invocation mechanism bandwidth, network bandwidth, devices such as video used by OLE2 [Microsoft 94].) Taken together, these frame buffers and sound cards, or higher-level three facilities enable a consistent end-to-end software-defined resources, which may themselves treatment to be applied to real-time scheduling manage or use other resources. decisions. • Resource Amount: An abstraction representing a • An I/O system that also schedules I/O operations quantity of a specific resource. This is represented by using the same real-time scheduling constraints. a number between zero and one, with one • A set of I/O and RPC abstractions designed to avoid representing 100% of a particular resource. Resource data copies when transmitting and operating on large amounts are derived by resource providers (see quantities of data. This mechanism is derived from below) from interface-specific quality-of-service Fbufs [Druschel & Peterson 93]. specifications supplied by interface clients. • 2.2 The Rialto Approach Resource Set: A set of (resource, resource amount) pairs. Resource management can be viewed as a • generalization of admission control. Unlike CPU or I/O Activity: The abstraction to which resources are scheduling decisions, resource management decisions allocated and against which resources usage is occur infrequently – typically at program startup, exit, or charged. Normally each distinct executing program mode change. Programs negotiate for the resources or application would be associated with a separate needed to operate on an ongoing basis in a given mode, activity. Activities may span address spaces and and then operate in that mode until either exiting or machines and may have multiple threads of control changing modes. associated with them. Threads execute with rights The Rialto programming model is designed to permit granted by secured user credentials associated with incremental development and refinement of the resource their activity. Examples of tasks that might be management code used by real-time programs. First, the executed as distinct activities are playing a studio- application can be developed (or ported) and its gross quality video stream, recording and transmitting real-time resource needs determined. Next, resource video for a video-conferencing application, and management calls can be added to cover the gross real- recording voice input for a speech recognition time resource requirements of the application, which is system. • still a relatively non-invasive change. Finally, real-time Resource Provider: The object that manages a scheduling constraints can be added to fine-tune the particular resource. Operations include allocating behavior of critical sections of code in the application. amounts of the resource to activities, performing The model carefully separates mechanisms and resource accounting as the resource is used by policies. This allows varied or dynamic resource activities, and notifying the resource planner of management policies to be used without modifying activities exceeding their resource allocations. The applications. resource provider object would typically be We intend to use this flexibility to implement user- implemented by the device driver that manages the centric, rather than application-centric, resource physical resource, by the scheduler (which manages management policies. By user-centric, we mean that they the CPU resource), by other parts of the system attempt to dynamically maximize the user’s perceived software (which manages other physical resources, utility of the entire system, rather than the performance of such as memory), or by the module that implements any particular application.