[Bioclusters] Mosix and Blast

[Joe Landman]

Hi Simon:

On Tue, 2002-05-14 at 13:29, Vsevolod Ilyushchenko wrote:
> Joe,
> 
> Thanks again!

My pleasure.  Glad to be of service!
 
> Could you please also take a look at my original questions at the beginning
> of the thread? Briefly, they are about:
> 
> 1. Will Mosix migrate commands that logically should not be migrated, like
> ifconfig?

I dont know.  I asked the folks on the open-mosix list to comment here
on these questions.

> 2. Is MFS/DFSA a striped network file system like PVFS or something more? I
> am somewhat confused by its /mfs/nodename... syntax. 

DFSA looks like an indirection layer, so that you think you are doing
local reads and writes, but the run-time library is catching calls to
the IO operations, seeing if they need redirection as requests to
another node, and then acting properly.  This is my take and it may be
wrong....  so lets see if I can get the Mosix folk to comment.  

If this understanding is correct, then DFSA is not a striped file system
layer.  It will be as fast as the network pipe minus some overhead delta
(can be large in some cases).  If in the whole chain of the file system
bit, the rate limiting factor in the DFSA and GFS system is the network,
you will likely see about a 10 MB/s IO limit at best (large block
sequential reads) over a 100 Base T.

The idea is look for the slowest link, and that will likely be the
bottleneck (not always, but it is a good bet).

> 3. Is it easy to alternate the cluster between Mosix and non-Mosix configs?

Define "easy" :)

My guess is that you would need to change between 2 different kernels,
and start the relevant services depending upon the output of the uname
command.

    [landman@squash.canton01.mi.comcast.net:~]
    15 >uname -r
    2.4.18-xfs
    
    [landman@crunch.canton01.mi.comcast.net:~]
    1 >uname -r
    2.4.5-5mdk
    
Just make sure that your kernel name changes between Mosix-ized and
non-mosixized kernels.  You would then have to do some monkeying with
/etc/lilo.conf (unless there is a better way) to set the default to
something other than where you are now, make sure /sbin/lilo succeeds,
and then reboot into the new mode.

It is possible, though it might actually be simpler (on person time etc)
to create a seperate partition with a non-Mosix-ized installation and
switch between the two as needed.  

> Also, after reading some more info on Mosix, two other problems:
> 
> 4. It's not clear whether Mosix migrates processes using shared memory. 
> (AFAIK blast uses shared memory.) Even if Mosix migrates such processes, is
> it possible that different threads of the same blast invocation will wind
> up on different nodes?

No.  BLAST uses pthreads, and Mosix could not migrate a thread.  I
believe it migrates at the process level.  Migrating BLAST would
probably be a Very Bad Thing(TM), as BLAST mmaps the database(s).  I do
not know what Mosix does with mmaps, but I have difficulty visualizing
how moving the memory map away from where the IO is occuring could be a
win.

> 5. Mosix docs underscore that it migrates processes to the nodes where they
> perform heavy I/O. However, I wonder whether it will be beneficial for our
> mode of work: we run many invocations of blast (almost) simultaneously
> until we run out of CPUs, and the processes all read the same database when
> they start. What is the best way to utilize Mosix here?

This is a hard question.  Would require thinking time.  I would probably
recommend speaking with Chris D (and his team) about this, and they may
be able to help.  Basically I think you need to talk to an IO + cluster
guru at this point (and that would be Chris) offline.

> 
> Thanks,
> Simon
> -- 
> Simon (Vsevolod ILyushchenko)   simonf@cshl.edu   
> http://www.simonf.com          simonf@simonf.com 
> 
> The central message of Buddhism is not 
> "every man for himself"!
> 				("The Fish Called Wanda")
> _______________________________________________
> Bioclusters maillist  -  Bioclusters@bioinformatics.org
> http://bioinformatics.org/mailman/listinfo/bioclusters
-- 
Joe Landman,
email: landman@scientificappliance.com
web  : http://scientificappliance.com