Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!brahms.udel.edu!gdtltr
From: gdtltr@chopin.udel.edu (root@research.bdi.com (Systems Research Supervisor))
Newsgroups: comp.os.misc
Subject: Re: process migration - status and availability
Message-ID: <16932@chopin.udel.edu>
Date: 16 Apr 91 19:21:03 GMT
References: <10422@pitt.UUCP>
Organization: Brain Dead Innovations, Inc. (BDI)
Lines: 30

In article <10422@pitt.UUCP> jonathan@cs.pitt.edu (Jonathan Eunice) writes:
=>
=>Why isn't process migration common?
=>
   Two reasons: 1) It is hard to do in general. There is more to a
process's state than most people realize, including the kernel state and
relationships with other processes. There is also the potential overhead
of copying the entire code and data across a network. There are a couple
papers on the subject that confirm this, but I don't have my bibliographical
stuff with me.
2) Depending on the system model, you may get comparable performance simply
by using load balancing when new processes are created and leaving them
where they go. The only case where I would want process migration is when
more than one long-running CPU-bound processes are assigned (erroneously)
to a single node. The most prominent use of processes migration I know of is
in Sprite, which primarily uses it as a policy tool: foreign processes
running on a user's idle workstation are evicted to their "home" node when
the user returns.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration



-- 
                            gdtltr@brahms.udel.edu
   _o_                      ----------------------                        _o_
 [|o o|]   Two CPU's are better than one; N CPU's would be real nice.   [|o o|]
  |_o_|           Disclaimer: I AM Brain Dead Innovations, Inc.          |_o_|