[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

MOSIX, again...

Hi fellows,


I spent a large part of Sunday's afternoon fighting with MOSIX.  I had
done this before, but now I had more time and less things in the
todo-queue.  It didn't go well.  I'd like to have some feedback from
people using MOSIX regarding how to package it for Debian.

First things first.  It's *absolutely* amazing how these people have
managed to make something as simple as applying a patch something
really cumbersome instead.  I have mailed the MOSIX group regarding
this issue and I hope I get some positive feedback.

Would someone here please explain to me what the heck is the
difference between the mosix and the mos directories?  mos is the
loadable module, and mosix is the kernel support for it, it would have
guessed, but it's not quite so.  If you peek at the top (patched)
Makefile, you'll see that in the case of building MOSIX as a module
something gets linked into the kernel and if building MOSIX in the
kernel something *different* is linked into the kernel.  So far so
good, but maybe I'm missing something obvious, but to me the current
code looks plain wrong.  Anyway, I'll be ignoring this issue for the
moment and I'll just work on the assumption that MOSIX *has to* be
built as a module and linking it into the kernel is not possible.

Then there's the versioning stuff.  I'm still trying to figure out why
these is needed or how it is used.  Basically a global symbol
"kernel_version" gets added *by hand* after the module has been
compiled but I can't find a reference to this symbol anywhere...
needless to say this is a horrible kludge, and I think calling it a
kludge is doing it a favour...  it's quite funny how things are done
regarding the internal MOSIX version.  IMHO it should use, for the
sake of readability, use KERNEL_VERSION and LINUX_VERSION_CODE.

Now, for the actual package, it's *necessary* to patch the kernel.  So
I'd guess the best way to handle this is to do the same thing the
various kernel-patch packages do, it would be something like
kernel-patch-2.2.13-mosix, which brings up another question.  Is mosix
*really* i386-specific?  I had a look at the assembler stuff, and it
doesn't seem to be i386-specific to me... has anyone tried to use/port
MOSIX on something not i386?

Then there's the user space programs... when I get to this point I'll
suffer, er, I mean, I'll take a look at taking the tarball out of the
package and build it *without* the mosix package installed.

And the biggest problem of the all... changing the default policy from
"take over the machine" to "do what I mean when I mean it".  I don't
want to divert tons and tons of stuff.  Has anyone looked at this? Is
it possible under MOSIX's desing? Can I just say:

$ load_balance_across_the_cluster this_heavy_computation

how does it work when "this_heavy_computation" is really a MPI program
spawning more programs?  What about I/O?

And regarding debian clusters in general, I've been away for a while,
in fact I'm no longer near the cluster I built, it's kind of ironic
that now that I have the time to work on these packages I don't have a
cluster to test them... anyway, I would like to encourage people on
this list to take a look at Joey's magnificent debconf package and
provide patches for packages commonly used in clusters (and here I
mean *anything* from a MTAs to ssh to lprng to mpi, but Cam is taking
good care of the last set) in order to get them to use debconf.  Being
able to preconfigure machines in the way debconf works *is* *the*
solution *we* cluster people have been waiting for for so long.  It's
there, it's implemented, it's good, now it's just a matter of using



Reply to: