lkml.org 
[lkml]   [1999]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Process migration -> MOSIX?
Hello,

Did you take a look at the recently GNU-released MOSIX? MOSIX does
process-migration based clustering.

The mailing list of MOSIX is at mosix-list-request@cs.huji.ac.il, a web
site is also somewhere (probably on the same server, otherwise ask
freshmeat or dejanews and you should be able to find it).

Prof. Amnon Barak is the project leader, and he's just released MOSIX
0.92.0 for Linux 2.2.10.

Cya,

Jelle.

On Sun, 20 Jun 1999, Trever Adams wrote (abbreviated)

> Process migration: You tell the kernel, I want to take this process
> home with me in a file to load on the _SAME_ archetecure, with hopefully
> the same file system, and definitely the _SAME_ OS. Kernel creates 1
> file. This file is basically a core dump, it saves ALL memory and CPU
> state for that application. It then tags onto the end, any necessary
> kernel structures that can't be remade when opening the "app file."
>
> Problems as I see them:
>
> 1) Open files: One way around this, and in which environment this would
> be most useful, would be an environment where all servers/workstations
> have the same "user" file systems. Provided via coda, nfs, or similar.
> I believe this is easy to do since you have file descriptors, you should
> be able to provide path name instead of inode or file descriptors. The
> kernel then could easily recreate state.
>
> 1b) Non similar file system space: The kernel should allow the user to
> say, well this wont be the same file system view... please append all
> the files I am using and give them a new name. I am not exactly sure
> how this would work, but it is possible.
>
> 2) Network connections (and hardware state for root device), and other
> non-transferable things: Sorry, the kernel should easily be able to say
> "This is a serial/network device/connection, we can't migrate this
> process.
>
> 2b) Some exceptions would be such special files as /dev/dsp and
> /dev/audio. This could be saved as what state they were in and that we
> had control.
>
> Honestly, I view this as a wonderful feature. I also have some ideas of
> where it would be useful, but don't really have any need at the moment.
> At the point where there is need, app state may just be easier to save
> in the app than to migrate the process. I thinkt he biggest gain for
> this would be in BeoWolf or other cluster environments.
>
> If this is a crazy idea or has problems, please don't flame me, just
> enlighten me. If there are tools that do just this, please let me
> know. I imagine suspend to disk is a similar idea since it has to save
> state... just wouldn't have so many special cases.
>
> Trever Adams


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.079 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site