Migration policy

[Raul Deluth Miller]

   >    * before you actually migrate, you allocate the resources, so that no
   >     uncontrolled massive migration waves are done on systems.
   > 
   > I think that being capability driven will do away with the need for
   > this kind of hack.

      Uh ? What's that ? I thought we agreed being able to see is
   being able to access. The pointer is the capability. So what
   exactly do you propose ?
      I mean that so that an unloaded machine would not be overflown
   with migrating objects, it would have to accept any object and
   allocate all needed resources *before* the object is actually
   migrated. That is, never migrate an object that may have to be
   bounced back or away. Note that this does not forbid gates to exist
   and try to migrate objects to farther networks.

I said the wrong thing -- I had forgotten about race conditions.

   >    * systems are (dynamically) hierarchically organized with each time
   >     more global resource servers.
   > 
   > I'm not sure of the significance of this one.

      I meant that to reduce traffic, networks can organize in trees,
   so that the migration decision process is simplified and
   accelerated.

Um -- clumping like with like and near with near, more or less?  I
think I agree.

   >    * you try to migrate objects that communicate heavily to machines
   >     that would reduce communication overhead.
   > 
   > This looks like more protocol design.

   What I meant is you must bring nearer objects that cause heavy
   network load. e.g. if you have some filter to question a far
   database, you'd better run it near the database...

Hmm.. yes.  I'd think of this as the object requires the database
capability.  Except it's not particularly meaningful for databases to
poll all clients looking for work, so I guess there needs to me some
sort of public interface object that accepts filter objects and hangs
on to them for when the database is ready.

   > For a large scale system, there need to be some objects which
   > tackle issues like getting things going, spotting/clearing
   > problems, optimizing communications, configuring new machines,
   > etc. etc. etc.  Ideally, at least a third of our work is going to
   > non-management work (which is a lot better than you can say of
   > lots of single-user systems).

   Yes. We need some extensible scheduler/optimizer.

I think the issues go quite a bit further than what's usually treated
in the concept of "schedule/optimizer".

-- 
Raul D. Miller          N=:((*/pq)&|)@                 NB. public e, y, n=:*/pq
<rockwell@nova.umd.edu> P=:*N/@:#               NB. */-.,e e.&factors t=:*/<:pq
                        1=t|e*d    NB. (,-:<:)pq is four large primes, e medium
x-:d P,:y=:e P,:x                  NB. (d P,:y)-:D P*:N^:(i.#D)y [. D=:|.@#.d