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:
-
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.
-
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:
-
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.
-
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.