CS 736 - Spring 2007 - Paper Discussion

Summary

In this paper, design and implementation of Mach memory management operations is examined. The paper also discusses the relationship between memory and communication and how it relates to the overall performance. Discussion on management of memory objects outside the kernel is also presented. Mach provides an abstraction called memory objects around which secondary storage management is structured. As a result, Mach can quite efficiently manage services like network paging and file system outside the kernel.

Problem Description

Treating memory and communication as duals inside the kernel can provide increased flexibility, better match between OS facilities and multiprocessors, and improved performance. The authors suggest that communication and virtual memory should play complementary roles, not only in organization of parallel applications, but in the implementation of the kernel itself.

Contributions

Mach external memory management interface is based on memory objects. Memory objects provide a layer of abstraction and are represented by a port. The main advantage of following this approach is that memory objects can be created and serviced by a user-level data manager task apart from the Mach kernel. Thus, user-level applications will have more flexibility to participate in decisions regarding secondary storage management and page replacement.
The remote procedure calls made by the kernel are asynchronous and the kernel does not have to wait for the acknowledgement of those calls. This makes the process of memory management quite efficient as the kernel does not have to wait for a call to return.
The authors also discuss how to use their memory subsystem to implement a minimal file system and a consistent network shared memory excerpt. This approach has two advantages. Firstly, it somewhat validates the memory management scheme that the authors propose. Secondly, people can use these examples as guidelines to implement other similar features.
The authors also discuss different problems that can arise in external memory management and they also discuss how to solve these problems. For example, to avoid deadlocks during page out operation, the authors propose that the kernel must reserve some amount of memory for itself.

Flaws

Some of the flaws in this paper are outlined below.
1. A lot of memory management decisions are left to the user-level applications. Even though this approach can be quite useful for certain type of applications like database related applications, it might not be required by a large set of other applications.
2. As user-level applications are allowed to manage the memory, the paper does not talk about how to prevent mishandling of memory resources by the user-level applications.
3. The paper does not present any evaluation of the proposed memory management model. Even though they discuss a lot of details about the model and how different features can be implemented using their model but they do not evaluate their design. Since Mach was highly motivated by Accent, the authors should have compared the performance of Mach with Accent to see how much efficient their memory management model was.

Relevance

The ideas presented in this paper of having ports and messages for communications between loosely coupled processors are quite frequently being used these days in cluster programming and network communication using socket programming.

Summary:
The paper presents design and implmentation of Mach operating system, with special emphasis on its seemless integration of virtual memory and communication.

Problem:
Mach was designed to build upon the strengths (performance through integration of virtual memory and communication, lack of I/O routines, distributed processing) and correct the weaknesses (portability, support/compatibility for legacy Unix apps) of another OS created in CMU, called Accent. The goal was also to come up with a kernel basis on which other OS could be built.

Contributions:
The biggest contribution of the paper is the notion of Memory Objects, that is central to the external memory management. They are represented as ports (an abstraction used in Accent - a communication channel), and allow data from disk accessed as if it is virtual memory and also allows user-level decisions on paging.

Another concept used is the use of same abstractions in kernel as well as user programs - for e.g. the kernel itself is a task with multiple threads of control, it has a default pager with memory port to provide backing store for kernel allocated memory)

Mapping the secondary storage into memory allowed simplified interfaces (no need for I/O routines) and performance (no need to read to OS buffer and then copy to user-buffer). This allows flexibility for the application developers to use the function provided by the kernel as is, or use a layer in between (with the traditional file systems) that allows refinements such as copy-on-write.

Flaws:
It is not entirely clear on how the peripheral interactions are done. It is hard to visualize (and implement) peripheral access through same mechanisms used for storage, though it can be done.

Since the kernel leaves many of the decisions to user-level data managers, it is quite easy for a misbehaving data manager to mess up the whole system. The paper doesnt talk about handling such cases, though it does talk about co-operative techniques of avoiding some of the potential issues. But malicious agents are seldom co-operative.

Relevance:
The Mach kernel presents a great idea for external memory management, and it has significance in many domains (databases, and other distributed data sharing applications) today.

Summary
The Mach system, developed at Carnegie-Mellon University, is presented in this paper with a focus on the memory management and communication mechanisms for inter-process communication. The concept of a memory object is presented and used to facilitate management by user programs and the sharing of data between processes running on different CPUs or different machines that are part of a network. The work evolved from the development of the Accent system which was built for a uni-processor environment.

Problems Addressed
The primary objectives of the Mach system are 1) Build an object oriented interface, 2) the support for both distributed computing and multiprocessors, 3) Portability between many different architectures and configurations, 4) compatibility with UNIX, and 5) performance comparable to UNIX. It seems as though this system was designed for real world applications where some of the other systems discussed so far are more to test or prove a concept and are not as practical for commercial use.

Contributions
The Mach system revolved around the basic unit of allocation, called a task, within which multiple light weight execution contexts could exist called threads. This two layer model for supporting concurrency within a task while not requiring a lot of resources to support a large number of tasks is an important idea to make systems more efficient and improve performance. Most entities within the Mach system are considered objects and can be operated on using a standard interface. The task is an object that creates ports for all its resources it wishes to export. In the same way when memory is needed a memory object is created that is accessed via a port. All interaction between objects within the system is accomplished by sending messages that utilize the ports of the participating objects. Memory objects are not solely under the control of the kernel and thus the memory system can be controlled to a certain extent by the user level programs that may wish to use varying models for the memory depending on the particular application.

Flaw
Though tasks would use ports to export resources it was not very clear as to how other processes that may want to use a particular resource of a different task would determine what port to use to gain accesses to the desired resource.

Relevance
The model presented in the paper of tasks being the basic unit of resource allocation and within them there may be multiple execution contexts is an idea that is used in most commercial operating systems to provide concurrency within processes. Also the work done on creating a system based on strict object interactions is very interesting and can be seen in many modern programming languages today.