From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue, 25 Apr 1995 01:46:07 -0400
From: Jas (Matthew K) matt@uts.EDU.AU
Subject: local and remote cpu resources and the acme model of interaction
Topicbox-Message-UUID: 0d8124c2-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19950425054607.ExT5p5G3ulI0_14qwYJ9fsmV8KUk3PAyMTEKbvvdSa0@z>

rob@plan9.att.com wrote this...
> 
> The real answer lies in further research.  We've started exploring the
> possibilities of more fine-grained distributatibilty, which would enable
> acme to have remote processes available, transparently, that could
> invoke all commands for it, yet keep all the symmetries.  Absent that,
> another possibility is a more ad hoc solution of starting explicit slaves
> across the network and communicating with them directly.  I've put
> that off in favor of, I hope, more help from the system itself.

i know this probably is an over simplification, but.. wouldnt it be
possible to just kill stop a process, make a copy of its address
space, copy that to a cpu server, and kill continue it? i would assume
this would be done when a process gives indications that it is cpu
intensive enough to warrant the move (this isnt that difficult to do).
text pages wold be apart of the namespace so that wouldnt need to be
copied, the only things needing copying would be any bss and data
pages. this would probably require another relocation of addresses
(difficult), or a re-doing of how addressing into data and bss pages
is done (ie all access would have to go through one extra level of
indeirection, just what you need for a performance hit). there are
probably alot of other considerations i havent even begun to
contemplate yet, this is more a stab in the dark, than a workable
solution.

			Matt
-- 
#!/bin/sh
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D3F204445524F42snlbxq'|dc;exit
Matthew Keenan   Systems Programmer   Information Technology Division
      University of Technology     Sydney Australia

It's nice to be in a position where people apologize because they
assume there's humor in your work, based on past experience,
but they're not sure where it is. -- Rob Pike