Migration policy

[Raul Deluth Miller]

Francois-Rene Rideau:
: >    * 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.

Next thing you know I'll forget how to type...

: >    * 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.  These trees should only be used for certain kinds of
control information, however -- and under certain circumstances
(parallel organizations) we should allow partial deferment of this
routing (non-root node passes thing off to its parallel, and merely
queues an info message back to the centralized root).  

Spanning trees can be a tremendous bottleneck, and we don't want to
use them for routine traffic if we can help it.

: >    * 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 as one of its selection criteria.  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