The Chronicler's Web (TCW)

By DAN CALLOWAY
Published 28 January 2010 @ 02:41 UTC

WEAVERVILLE, NC – An Operating System (OS) is designed to run on either desktop or network platforms. For the sake of brevity in this article, I will limit my discussion, for the most part, to user desktop platforms.

A desktop OS is essentially designed to be the interface between the hardware (including the CPU) and the user, wherein it is primarily responsible for the management of the hardware and activities that run on the computer as well any applications that may be running within the OS. The OS also provides the graphical user interface (GUI) where it exists, in order to make the computer more user friendly for the user. As the host for running applications on the computer, the OS is also responsible for the hardware, scheduling of system resources to support the applications, and the access protection for the hardware. When services are requested on the desktop, the kernel of the OS creates a process by assigning memory and other resources, establishing a priority for the process (in multi-tasking systems), loading program code into memory, and executing the program. The program then interacts with the user and/or other devices and performs its intended function.

Regardless of OS installed on the desktop, OSes provide application services to both programs running on the computer or to the user through the use of Application Program Interfaces (APIs) or, in some instances, program system calls. When invoked by the user or by another program running on the computer, system calls or APIs request services from the OS, pass parameters, and receive the results of the operation. As mentioned, users can interact with the OS either through the GUI or by Command-line Interface (CLI) to request services from the OS. On desktop computers, these interfaces are usually considered part of the OS. However, on larger multi-user systems running UNIX, UNIX-like, or VMS OSes on mainframes or mini-mainframes, the user interface is typically a program that runs outside of the OS itself.

As parallelism increases on the desktop platform; that is, as more and more processors are added and processing takes place through multi-core and multi-threaded environments, the impact that such increases in parallelism has on the OS is related to what is referred to as application workload or process scheduling and is directly related to this increased complexity. Thus, increasing parallelism would have a detrimental impact on OS functionality unless the OS is redesigned to accommodate this increase. Frachtenburg and Etsion (n.d.) suggest that as the average desktop workload grows more parallel and more complex, current OSes are not adequate to support the growing parallelization to handle this increase in computer parallelism. Frachtenburg and Etsion contend that parallel process scheduling required to efficiently run desktop platforms and their applications in a supercomputing environment cannot be achieved unless the OS is redesigned to handle the increased workload. Through case studies in their paper, Frachtenburn and Etsion demonstrate that one possible solution to this inadequacy of existing OSes might be to redesign the OS process schedulers with an understanding of the requirements of all process classes and their mixes, as well the abilities of the underlying architecture.

Frachtenburg and Etsion (n.d.) state: “The predominant approach to multiprocessing in general purpose [OSes] is to treat each processing element as an independent entity—processes/threads are migrated between processing elements in an attempt to balance cache affinity needs with CPU load imbalance” (p. 2). As a result, the general-purpose scheduler within the OS is too focused on handling a small set of requirements and misses the big picture, and overlooks two requirements that are critical in maintaining performance and efficiency for parallel desktop workloads: separation of co-interfering processes and co-scheduling of collaborating processes. Thus, these are two specific redesign considerations within the OS that Frachtenburg and Etsion suggest are necessary as parallelism is increased on the workstation.

Giacomoni and Vachharajani (n.d.) concur with Frachtenburg and Etsion (n.d.) in their assumption that in order to realize the potential of pipeline-parallel software as parallelism increases on the desktop, requires a reexamination of some basic historical assumptions in OS design, including the purpose of time-sharing and the nature of applications. Multicore architectures make it possible to fully dedicate resources as needed without compromising existing OS services. Giacomoni and Vachharajani describe the minimal OS extensions necessary to support efficient pipeline parallel applications on multicore systems and support their claims with evidence produced from the domain of network frame processing.

Giacomoni and Vachharajani (n.d.) contend that “maintaining a smoothly flowing pipeline, that is a pipeline where a datum is never waiting for processor time, requires the system to provide a zero-stall guarantee” (p. 4). Furthermore, “Pipelines implemented in hardware are based on this guarantee and ensure it by having every stage operate in lockstep with a uniform stage length of 1 cycle” (p. 4.). Operating systems that run on single-processor desktops, in general, do not make this guarantee as they have been built on the principle of timesharing resources. Multicore systems are different and OSes that support them “must be able to provide abundant processing resources permitting a system to use selective timesharing and fully dedicate resources to an application for an extended period of time. With dedicated resources it is possible to achieve the zero-stall guarantee” (Giacomoni & Vachharajani, nd., p. 4.). Giacomoni and Vachharajani argue that realizing these improvements require the operating system to be redesigned in order to provide a zero-stall guarantee. Meeting this zero-stall guarantee for any pipeline requires that the system: (1) fully dedicates sufficient computational resources to the application and (2) provides a set of pipe-lineable services. Finally, supporting a pipeline that spans multiple execution contexts requires a new abstraction to label the pipeline as single entity for resource allocation and security.

References:

Frachtenburg, E., & Etsion, Y. (nd.). Hardware Parallelism: Are Operating Systems Ready? (Case Studies in Mis Scheduling) . Los Alamos National Laboratory, Modeling, Algorithms, and Informatics Group School of Computer Science and Engineering. Los Alamos, NM: Defense Advanced Research Projects Agency (DARPA).

Giacomoni, J., & Vachharajani, M. (n.d.). Operating System Support for Pipeline Parallelism on Multicore Architectures. University of Colorado at Boulder. Boulder: University of Colorado at Boulder.

Dan Calloway