openMosix at 2.6

openMosix is nearing the first 2.6 releases. Not all features have been ported yet but beta testers are currently running and testing it. The goal is to have a similar zero configuration environment such as with the 2.4 series while trying to move as many features as possible out of kernel space and into user space. Amongst the reasons for doing this is the fact that new developers will probably easier end up writing patches for userland code in C , Python or Perl than start digging into actual kernel code.

With 2.6 we will also separate the architecture dependant an independant code, this way new ports for e.g. ppc will be possible.

All the openmosix related files that used to be in /proc/${pid} have been moved to /proc/${pid}/om. In 2.4 nodes were identified by a nodeide, from 2.6 on nodes will be identified by their network address.

As userland code is still underdevelopment one has to manually migrate a task. This can be done by running

echo "$ip" > /proc/$pid/om/where

echo "home" > /proc/$pid/om/where 

We currently don't have an autoloadbalancer in kernelspace anymore , migration has to be done in userspace. 2.4 userland tools cannot be used for 2.6 Vincent Hanquez wrote a Python based omd as proof of concept that does discovery, information balancing and task migration election. However the initial development of the userland code was done by a team of students at the Ecole Polytechnique de l'Universite de Tours, under the lead of Matthieu Perotin. Mathieu however wants to rewrite them in C++ before they will be really ready for production.

The design for these userland tools has been documented in a new paper by Matthieu Perotin. He documents that a migration agent will run on each node, and has to be aware of the state of other nodes, hence know information such as the average cpu load, the memory used, the cpu type and the available memory etc. In pre 2.6 versions all of this information was gathered in the openMosix kernel and this will now be moved to userspace.

The omd process will read data from the /proc interface of its own host. It then broad- or multicast it to the other nodes on the network. A scheduler process will read this broadcasted information and make migration decisions.