Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!udel!brahms.udel.edu!gdtltr
From: gdtltr@brahms.udel.edu (root@research.bdi.com (Systems Research Supervisor))
Newsgroups: comp.os.misc
Subject: Re: process migration - status and availability
Message-ID: <20591@brahms.udel.edu>
Date: 19 Apr 91 14:11:51 GMT
References: <10422@pitt.UUCP> <16932@chopin.udel.edu> <3057@redstar.cs.qmw.ac.uk>
Organization: Brain Dead Innovations, Inc. (BDI)
Lines: 29

In article <3057@redstar.cs.qmw.ac.uk> timk@cs.qmw.ac.uk (Tim Kindberg) writes:
=>In <16932@chopin.udel.edu> gdtltr@chopin.udel.edu (root@research.bdi.com 
=>(Systems Research Supervisor)) writes:
=>
=>>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)
=>Erroneously? Who/what knew they were going to be CPU bound?

   I suppose my above not-terribly-well-thought-out statement reflects a
subconscious desire for more intelligent process behavior prediction. In
any case, I am most familiar with the Amoeba processor pool model, in which
the normal case would have the processes running on different processors
anyway. Of course, if Dr. Douglis is correct in his estimate of the complexity
of adding process migration to Amoeba, I certainly have no objections. It
can certainly be used to support a number of scheduling policies. If MP
can be done without a significant reduction in system performance or major
increase in kernel complexity, there is little reason not to put it in.

                                        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_|