The structure of a multi-service operating system

This position paper describes research in progress into a new approach to structuring an operating system. This approach is intended to facilitate the provision of “Quality of Service” guarantees of resource allocation to applications, in particular those which perform computation on continuous media data in real time. The work is being carried out by the author in the context of the Nemesis operating system being developped by the Pegasus Esprit project. This position paper was presented at the 1994 Cabernet Workshop in Dublin, March 1994. 1 Operating SystemAbstractions The virtual machines provided by traditional operating systems sucessfully hidemany resource allocation problems by abstracting the resources involved; thus real time (or CPU time) is replaced by time on a virtual processor, physical store is replaced by virtual store, devices by filing systems and network protocols, etc. Much recent research has attempted to take this further: for example message passing over a network is replaced by distributed shared virtual memory. The aim of these mechanisms is to make the construction of a typical application easier: the application no longer concerns itself with the resource allocation it is receiving from the system or the protection boundaries between it and other tasks. Viewed another way, current workstation operating systems only offer a “best-effort” QoS to applications. Unfortunately, the information hidden by such abstractions (the passage of real time, the physical memory used by the application, network performance, etc) is precisely the information required by second-generation distributed multimedia applications1. Not only is information not available as to resource allocation, but no mechanisms 1[Hay93] defines a second-generation multimedia application as one which performs real-time computation on data streams rather than just presenting them to human users. 4 The Large-scale structure of Nemesis exist for an application to manage the resources it has and share them among its own component activities. For example, single-application CPU schedulers with functionality like scheduler activations ([ABLL92]) or Psyche ([SLM90]) are rarely used for multimedia applications. Even threads are only just coming into widespread use as a programming paradigm. 2 ImplementationofOperating Systems Functions Most operating systems implement shared functionality such as network protocols, filing systems, paging and scheduling in servers which run in separate protection domains (The Unix kernel can be viewed as one very large server providing a variety of services). It is not clear which application a server is logically executing at any one time; for example in conventional Unix most of the processing of an incoming TCP packet is carried out before it is known which process the packet is intended for. Quite apart from efficiency overheads this approach makes it largely impossible to account resource usage to a particular application. Providing negotiated levels of resource allocation (including, but not limited to, CPU time) to applications in such a system is at best unreliable and insecure, at worst impossible.