Re: Process migration -> MOSIX?
Rogier Wolff (R.E.Wolff@BitWizard.nl)
Sat, 26 Jun 1999 09:53:08 +0200 (MEST)
> 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.
Some people pop up every time saying that the whole idea is bad
because we can't restart network connections. My opinion is always
that it doesn't really matter if we can't migrate 100% of the
processes at first. Moreover, even if we get stuck and never will be
able to migrate everything, then we can still note it in the
"restrictions" section of the manual.
On the other hand, we HAVE the infrastructure to migrate network
connections. On the box where the process is "leaving" we can
create a masquerading entry that creates a through-connection for
external hosts. If the network connection is towards another Linux
machine, we can have that host enter a masquerading entry for the
outgoing connection.
Anyway, a friend just told me that SGI has a process migrating system
where there are a few "restrictions" in the manual, which indicate
that processes with network connections cannot be migrated. Ok.
Acceptable solution. Already extremely useful.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
-
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/