Hi all,
the subject may be too ambitious, but thats not a prank i am
playing... As a graduation project i intended to make linux distributed...
by distributed i mean, enabling process migration, selecting eligible
nodes, and ofcourse selecting candidate processes which would be migrated
to the selected node. The following is the description of how i intended
to do and would like inputs/suggessions from the gurus here.
The processes would be dynamically migrated from one node to the other
based on the selections of local process (candidate) and the remote node.
The entire task along with its memory map will be migrated on to the other
system (This system however would be later changed to migrate only
referenced pages). The guest system (where the process originated) would
however have a pseudo process running on it, which would not take much
resources but would help in handling various signals/interrupts and in
handling system calls. This method of handling helps is in migrating the
user mode execution (which is on an average greater than 75%) to some
other system on the network thus reducing the load on the guest system.
As of now i am trying to device a migration system where the system mode
computation is mostly carried out on the tasks original system, as this
simplifies the implementation and helps maintaining the speed and
efficiency in cases where the distribution is not needed.
Prasad
--
Failure is not an option
> As a graduation project i intended to make linux distributed
You mean, like Mosix?
http://www.mosix.org/
--
Playing fast is easier than playing slow.
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
On 2002-11-10T16:34:10,
Prasad <[email protected]> said:
> As of now i am trying to device a migration system where the system mode
> computation is mostly carried out on the tasks original system, as this
> simplifies the implementation and helps maintaining the speed and
> efficiency in cases where the distribution is not needed.
Look at OpenMosix and the Compaq Single System Image cluster stuff.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Principal Squirrel
SuSE Labs - Research & Development, SuSE Linux AG
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
-- Capt. Edward A. Murphy -- Louis Pasteur
> As a graduation project i intended to make linux distributed
This is what exactly openSSI project does. http://ssic-linux.sf.net
>The processes would be dynamically migrated from one node to the other
>based on the selections of local process (candidate) and the remote
>node.
In the case of SSI the process to be migrated is selected by using
mosix algorithm. If mosix load balancer is not enabled automatic load
balancing doesn't work. But you can use the migrate() call with "best
node" argument so that the average load on the machine is used to
determine which node the process should migrate.
>The entire task along with its memory map will be migrated on to the
>other system
SSI even support mmap across cluster. That means you can even ask a
process that has done a mmap of file to migrate to another node.
>The guest system (where the process originated) would
>however have a pseudo process running on it, which would not take much
>resources but would help in handling various signals/
SSI support cluster wide signaling. That means you can send signal to a
process running on other node( you have cluster wide PID )
It also support cluster wide message queue, DLM , cluster wide device
access and cluster wide IP. The developers are working on cluster wide
support for semaphore shared memory
NOTE: it support three architectures. x86/IA64/Alpha
-aneesh
> > As a graduation project i intended to make linux distributed
snip
>
> >The guest system (where the process originated) would
> >however have a pseudo process running on it, which would not take much
> >resources but would help in handling various signals/
>
> SSI support cluster wide signaling. That means you can send signal to a
> process running on other node( you have cluster wide PID )
>
The openSSI process model is quite different than Bproc or Mosix or
your "guest system" proposal. In the openSSI model, there is no
pseudo or shadow process at the processes creation node; after
a processes migrates, all its system calls are executed on the new
node and signalling to the process is done directly to the process on
the new node. Besides the obvious performance advantages this can
give, it can also provide availability advantages because the
creation node can go down without taking the process down with it.
bruce
>
> -aneesh
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> To learn the basics of securing your web site with SSL,
> click here to get a FREE TRIAL of a Thawte Server Certificate:
> http://www.gothawte.com/rd522.html
> _______________________________________________
> ssic-linux-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel
On Wed, 13 Nov 2002, Bruce Walker wrote:
> > > As a graduation project i intended to make linux distributed
>
> snip
> >
> > >The guest system (where the process originated) would
> > >however have a pseudo process running on it, which would not take much
> > >resources but would help in handling various signals/
> >
> > SSI support cluster wide signaling. That means you can send signal to a
> > process running on other node( you have cluster wide PID )
> >
> The openSSI process model is quite different than Bproc or Mosix or
> your "guest system" proposal. In the openSSI model, there is no
> pseudo or shadow process at the processes creation node; after
> a processes migrates, all its system calls are executed on the new
> node and signalling to the process is done directly to the process on
> the new node. Besides the obvious performance advantages this can
> give, it can also provide availability advantages because the
> creation node can go down without taking the process down with it.
>
Yeah, openSSI approach has some advantages, but how about the other side,
how are the devices and files being handled? isn't it wrong to run
someone elses process when the data that he is supposed to provide is
missing? My work is based on a workstation model where all the nodes are
independent workstations (in most cases with similar configurations, as in
a computer laboratory at a university). One of my major constraints is
that the system should be binary compatible with the kernel that does not
support my model. In my case i plan packing and restarting a process when
the creation node goes down.
Prasad.
> bruce
>
> > -aneesh
> >
--
Failure is not an option
>
> Yeah, openSSI approach has some advantages, but how about the other side,
> how are the devices and files being handled? isn't it wrong to run
> someone elses process when the data that he is supposed to provide is
> missing? My work is based on a workstation model where all the nodes are
> independent workstations (in most cases with similar configurations, as in
> a computer laboratory at a university). One of my major constraints is
> that the system should be binary compatible with the kernel that does not
> support my model. In my case i plan packing and restarting a process when
> the creation node goes down.
>
> Prasad.
>
Missed something in my previous one... even i am migrating only part of
the system mode computations on the creation node. They only include the
device/filesystem handling syscalls. Most of the other things, that
correspond to the process and memory management are being executed on the
host system itself.
Prasad.
--
Failure is not an option