CSC 573

Linux Internals

A Global View of Processes on the Cluster

Alina Beygelzimer, Chris Homan

The goal of this project is to create a global identification system for processes across a network.  Such a system could potentially support two other long term projects of interest to the Rochester systems group:

  1. Using this global virtual name space as a facility for process migration. Process migration is a means for dynamic load balancing that moves work from overloaded nodes to idle nodes.  It can also improve fault tolerance, by evacuating processes from dying hosts.  Ideally, applications should work with objects (processes, files) in a common, location independent name space.  The Nomad system provides a user-level service that allows processes to designate themselves migrateable (only checkpointing is done in the kernel).  Nomad is designed to be as decentralized as possible, to improve scaleability.  Currently, Nomad does not provide services for the global identification of processes.
  2. Leveraging the Feeley global virtual memory management system:  what does giving a network of computers the same virtual address space give us for free?  It seems that, at the least, we should consider moving global process identification---and perhaps process migration ---into the kernel.
We expect to implement some kind of virtual name space in which we keep one global process table.  The table maps virtual process IDs to the host PID where the process is currently running.    The virtual PIDs remain stable throughout the lifetime of a job, but the host PID may change with each restart of the process. At a lower level, there is a crucial design decision:  we can completely abandon the location-dependent Linux name spaces, and modify the kernel so that it assigns globally unique virtual process ID's to newly created processes (in which the virtual name space does very little translation)?  Or we could maintain a virtual process table and virtual address tables (as described above) to map between the virtual and current real names?  How does having having a global virtual memory management system, as opposed to having just Nomad, affect the answers to these questions?

For now, we know of the following tradeoffs between an implementation that lies above the kernel's system call interface and an implementation that lies below:

  1. A modified kernel would be completely transparent to the processes and would work with any unmodified binary program. In a modified kernel we would also have easy access to the process state that is stored in the task structure.
  2. A user level system will most likely limit the kinds of applications the system can handle and offer only limited transparency.  However, user-level systems are easier to implement and maintain than are in-kernel systems. We could use a modified system library that replaces the system call functions with wraps that translate the arguments from the virtual name space into the underlying location dependent Linux name spaces, and vice versa. Application programs would then need to be linked with this special library.