[Biodevelopers] Re: [Bioclusters] Clueless about Mosix

[Joe Landman]

(cc'ing the developers list, as these topics may be of interest to
others)

On Tue, 2002-05-14 at 11:00, Ivo Grosse wrote:
> Chris Dagdigian <dag at sonsorol.org> wrote on Mon, 13 May 2002:
> 
> > It would be counter productive if they were not aware of each other -- 
> > if they played nicely together then there is certainly a place for batch 
> > scheduling in a MOSIX-type environment.
> 
> I have a few naive (and losely coupled) questions:
> 
> 1. even if Mosix and the scheduler were aware of each other, but would 
> operate on the same time scale, then that could (theoretically) lead to 
> terrible confusion (oscillations, resonance, even chaos ... in the 
> sense of nonlinear dynamics and chaos theory), correct?  Do those 
> phenomena occur in reality?  What are the time scales of Mosix and 
> typical schedulers, say, SGE?  I mean:

All of this is tunable, so you should be able to escape realms of
thrashing.  Hopefully Ron Chen can speak to how to tune SGE, and lets
see if we can get Moshe Bar to comment on tuning Mosix.

> - how often does Mosix check the state of the nodes?  (Once every 
> second?)

This would need to be answered by a Mosix guru.

> - how often does SGE check the state of the nodes?

Not sure, but as I remember, SGE doesnt poll the nodes, the nodes do
effectively "pulls" from the server.

> - how long does it take a process to be migrated, or to be started?

Ugh... process start is fast (maybe a few percent off the normal start,
due to more state information).  Process migration is basically
snapshotting CPU, memory, socket, file handle state and transporting
them to remote system.  It should not be that long on a lightly loaded
server, though it can be on a heavily loaded server.

Under Scyld (Don, correct me if I am wrong), this process is done on a
"head" node and transported to the computing nodes.  Under Mosix, every
node is a head node... or something like that.  It is a somewhat
different model of computing.  Scyld is more true SSI, though I dont
think you can malloc more memory than a computing node has and use a
distributed shared memory bit.  This would be cool though.  Mosix is
more of a process migrator with pipes back to the original running
machine.

I defer of course to the Mosix and Scyld experts on this.

> 2. can Mosix be used without a scheduler?  I mean: assume we start 
> 100,000 jobs on a 100-nodes cluster.  Is Mosix smart enough to start 
> only 100 jobs and keep the others in a queue?

You should be able to use the native "batch" command.  See the man
page.  This might not work very well though, as batch is a really
minimal scheduler... wakes up and looks at CPU load.  If load is less
than 0.7, then launch next job in queue.

> 3. if Mosix is not smart enough to do job queuing, then I think there 
> *must* be schedulers that work together with Mosix.  Hi Mosix users, 
> which schedulers do you use?  Did you encounter any confusion phenomena 
> (see question 1.) where the scheduler and Mosix trick each other?

I think Mosix can be told to migrate or not migrate a process.  This can
be set at runtime as I remember.  Scyld has a different concept, where
the migration needs to occur to free up the head for its other tasks. 
Here a scheduler is needed, but it would need to be instructed about how
to deal with Scyld (which Don and team have done with PBS).

> A Mosix-unrelated question:
> 
> 4. SGE is capable of rearranging jobs in the queue according to 
> priority.  But is SGE capable of stopping already running jobs if 
> higher-priority jobs are in the queue?  If not, which schedulers can do 
> that?

I know LSF can do this via checkpointing.  I dont know what SGE
can/cannot do in this area.  I presume something similar.

> 
> Best regards, Ivo
> 
> _______________________________________________
> Bioclusters maillist  -  Bioclusters at bioinformatics.org
> http://bioinformatics.org/mailman/listinfo/bioclusters
-- 
Joe Landman,
email: landman at scientificappliance.com
web  : http://scientificappliance.com