Dynamite: transparent load balancing under PVM
Dynamite
The combined computing capacity of the workstations that are present in many
organisations nowadays is often under-utilised, as the performance for
parallel programs is unpredictable. Load balancing through dynamic task
re-allocation can help to obtain a more reliable performance.
Dynamite (also known as DPVM) provides such an automated load balancing
system. It can migrate tasks that are part of a parallel
program using a message passing library. Currently
Dynamite supports PVM only, but it is being extended
to support MPI as well. The Dynamite package is completely
transparent, i.e. neither system (kernel) nor application
source code need to be modified.
Dynamite supports migration of tasks using dynamically linked libraries,
open files and both direct and indirect PVM communication. Monitors and
a scheduler are included.
- Installation of the checkpointer is described on its own page
- Dynamic PVM is a drop-in replacement for the standard PVM, and
its installation is basically identical to that of the standard
PVM. Just set your PVM_ROOT, PVM_ARCH and
PATH correctly.
Note: if you are not compiling for Solaris/Sparc, you will
need to modify src/Makefile.aimk by removing
sigprocmaskhard.o form the list of objects to link
(LOBJ).
-
The installation of the monitor is also fairly straightforward.
As before, the provided Makefile is ready for Solaris and
needs some minor adjustments under Linux. You will need to switch
ARCH, LIBS and mon_slave to the
alternate definitions, which are by default commented out in the
Makefile.
- You need to link your PVM application with Dynamite dynamic
loader (as described here) and with
the replacement Dynamite PVM library.
- Initialize Dynamic PVM just like the standard PVM by invoking
its console pvm, adding new machines etc.
- Start your PVM application as usually.
- You can now perform migrations manually, using move
command in the PVM console. move accepts two arguments:
the task identifier of the task to migrate and the node name (as
printed by conf) of the node where the task is to be
migrated to.
- To perform migrations automatically, you need to start the
monitor. Before doing that however, you need to provide a
suitable configuration file:
- A sample configuration file resource.txt is
distributed with the monitor, but you need to tailor it to
your local environment.
- Adjust START_SLAVE_COMMAND to point to your
installed copy of the monitor slave. You can leave
DUMP_DIR intact, as it is only used when debugging
(off by default).
- List all the nodes that you want to have monitored. For
each node, you need to provide the host name and IP address,
and optionally relative CPU and memory weights of this host
with respect to other hosts (1.0 by default). Please note
that due to parser deficiencies you need to terminate your
lines with Tab if you do not supply the optional
fields.
You can start the monitor by invoking the monitor
command, providing the path to the configuration file as an
argument. This path should be absolute. monitor will
start mon_slave tasks on the other nodes, and based on
the information from slave monitors it will instruct Dynamic PVM
to perform necessary migrations.
A new version of DPVM package
(DPVM 2.0) is available for the new
Dynamite Checkpointer 2.0. Basically, it is the
older version slightly modified to work well with the new
checkpointer facility. The new package is thus designed to
support glibc-2.2.5-linked user programs. However, the current
state of DPVM 2.0 has some limitations:
- It can not properly support PVM in-place communication.
Parallel programs basing on this method of messaging are vulnerable
to checkpointing process and (in many cases) unable to restart.
- The user is obliged to make sure her process will not checkpoint
while calling system routine from malloc() family. The DPVM
checkpointing mechanism uses this allocation facility on its own and
this introduces inconsistency in internal structures of memory allocation
subsystem. The most straightforward solution is to provide a wrapper for
allocation routine which makes sure the SIGUSR1 signal is
blocked during system call.
Instructions concerning installation and usage of this package as well
as its documentation stay the same as in the previous version.
