HLL Process Model

[Chris Harris]

As development seems to be progressing on the HLL front, I thought I'd
again re-interate some suggestions on the process model, and throw out
a few new things too.


They say most CPUs are idle most of the time.  So perhaps on a good
day, a network with 500 CPUs may have 300 in use--just 60%
utilization.  As CPUs cost a good deal of money, TUNES should avoid
this situation and provide the highest CPU utilization as possible.
(90% seems like a good amount.)

How, with so few processes and so many processors, can TUNES possibly
near the 90% utilization?  My suggestion is to dump the big, ugly,
linear process model in favor of something more flexible and scalable.

In real life, fine-grained objects don't require big, fat processes
to do their operations, so why should they in a computing environment?

In my view of things, code should have some way of being represented, so
that it is easy to distinguish code that must be executed linearly from
that which can be executed in parallel.  (No judgements at this level
would be made about what SHOULD be done in parallel.)

TUNES, then, would constantly keep an eye out for how much of the CPU
is currently being used.  This could be done by AI techniques, genetic
algorithms, whatever.

One possibility would be to imbed linear and non-linear code embedded within
each other.  For example:

VARIABLES
  i, j

BEGIN PARALLEL CODE
  beep
  BEGIN LINEAR CODE
    i = 0
    UNTIL quitting
      BEGIN PARALLEL CODE
        i++
        j = random number
      END PARALLEL CODE
      print i-j
    END UNTIL
  END LINEAR CODE
END PARALLEL CODE

This is a rather useless program.  Basically, it's function is to beep
once, and then display the result of the subtraction again and again.
The important part, though, is not what it does, but how the PARALLEL
and LINEAR specifiers work.  All code between begin and end PARALLELs
will function if its members are not executed sequentially.  All code
between LINEARs will be executed "normally".  This does NOT mean that
all code between PARALLELs WILL be executed non-linearly; it simply
means that such a possibility exists, should the OS find it
worthwhile.

How does the OS tinker with a process?  Well, if utilization is too
low, it will break off one (or a few) of the sub-blocks in a process,
and spawn them as seperate processes.  If the machine is being
over-utilized, it will combine existing processes together.  (You
could just leave them seperate, but maybe that'd have more context
switch overhead.  I dunno....)  Certain processes should also be able
to specify attributes that they have, so that they might take
advantage of any special hardware availible.  For example, if there is
hardware availible for the speedy execution of celluar automa
programs, there is no reason the process, without much of its
knowledge, should be able to take advantage of such.

If we support changing of a process' code on the fly, we can then view
the OS as one huge process, composed of manys smaller things....

The main conceptual problem I have with this model is how to apply
quotas and such, when process are constantly growing, shrinking and
migrating.  I guess how many processes a user is running now could be
a factor in determining which sub-process to spawn as a seperate process.

The other alternative I have to this is the cell model I proposed.
(Remember that these are NOT the same cells that Mike proposed.) The
basics of what I said:
  -Basic unit of processing is the cell.
  -Cells are composed of an internal group of sub-cells.  
  -Cells are connected via one-directional channels.
  -There are a few primitive cells, that allow for the execution of
   low-level code, such as math.
  -Cells have no internal storage; they get all their inputs from
   other cells.  (So we maybe need some variable primitives.)
  -The OS can roll sub-cells into their own, first order cells, to
   achieve higher CPU utilization.  It can also roll a number of
   interdependent first-order cells to be sub-cells of another
   first-order cells, if resource utilization is too high.  (This
   happend at all levels, too.  2nd-order cells, for example, can be
   merged to form 3rd-level cells.)

I'm not sure if the overhead involved in this would be really gross,
or if it would be barable.  Actually, that might also be a problem
with my first model too, depending on how it was implimented.  Any
ideas?


So now that we've taken that conceptual leap, why not take it a step
further, and have resizable, self-enclosing objects, and view the OS
as one huge object, composed of many sub-objects?  Sure, there are
logical 1st order objects, but the actual physical storage should change 
on the fly, so that every object, be it 40 gigs or 20 bytes, should be able
to best utilize mass-storage resources.


Maybe there would be some way to combine processes and objects into
one concept, as they have sort of done is BETA.  That'd certainly be
neat, but the two are probably seperate enough that it might not be
worthwhile.

Wow, there's a mouthful!  I think I'll throw this out now, and bar any
further delay....

-Chris


-----------------------------------------------------------------------
"Ignorance is bliss, but where do you get the idea that knowledge can't
be even better?" -- me (Chris Harris <chharris@u.washington.edu>)
Check out my web page: http://weber.u.washington.edu/chharris