"cpu" command, other related stuff

"cpu" command, other related stuff

[Boyd]

    From: Photon <photon@nol.net>

    Have a list of cpu servers stored in some variable (i.e. $cpus), and have
    the cpu command remotely check the load average of each cpu server in the
    list, and pick the one with the lowest load average.  This would allow for
    better balancing of jobs in a large multi-cpuserver, multi-user
    environment.

if you really wanted to do this, i wouldn't break cpu.  i'd write findcpu:

   cpu -h `{findcpu}

or you could use it to set $cpu at login.

i think cpu was intended to be used with a particular cpu server, not
just one with a low 'load average' [a totally foreign concept to plan
9].  the choice being based on a particular function that cpu fulfills.

"cpu" command, other related stuff

[Nigel]

> if you really wanted to do this, i wouldn't break cpu.  i'd write findcpu:
>
>    cpu -h `{findcpu}
>
> or you could use it to set $cpu at login.
>
> i think cpu was intended to be used with a particular cpu server, not
> just one with a low 'load average' [a totally foreign concept to plan
> 9].  the choice being based on a particular function that cpu fulfills.
>
Also, making the decision once at the start is about as much use as a
chocolate teapot, since you might well stay connected to a CPU server
for days. In a 'real' system you might wish to choose the cpu
with the fast link to the fileserver where your files live.


Nigel Roles

"cpu" command, other related stuff

[Photon]

I _still_ haven't installed my plan 9 yet (waiting for more hardware to
arrive so I can do it "right" the first time), so all of this is based on
suppositions from intensley reading (drooling) over the books...

regarding the cpu command, it is my understanding that unless a specific
cpu server is named, the job is sent to server $cpu.  A better default
action might be this:

Have a list of cpu servers stored in some variable (i.e. $cpus), and have
the cpu command remotely check the load average of each cpu server in the
list, and pick the one with the lowest load average.  This would allow for
better balancing of jobs in a large multi-cpuserver, multi-user
environment.

Another idea I had along the same topic was...

Have a configurable value for each cpu server called maxload.  When this
option is set, the cpu server will refuse to handle any new jobs from
terminals when the load average is above "maxload".  You could even have a
"resumeload" value for when it should begin accepting jobs again.  i.e.
you could set maxload at 6.00, and resumeload down at 4.00, to give some
"recovery time".

The two ideas could even be incorporated together, allowing the cpu
command to pick the cpu with the lowest load average which is still
accepting jobs.  Of course, you could still manually specify which cpu
server to use on the command line, and of course, the manually chosen cpu
server could still refuse you for load average reasons.

The only problem I see with this scenario is (now this part is delving
into things about plan 9 that I don't fully understand yet, so bear with
me) that a runaway job could lock everyone out of a cpu server.  Possibly
the authenticated user who is the "owner" of the cpu server (isn't there
some assocation between a physical machine and the userid of the person
who owns the hardware and should have access to it?) could be allowed a -f
flag to "cpu" to "force" a job or shell on the cpu server regardless of
load average, so that he/she can always get into the machine....
Or maybe everyone can be allowed to "force" jobs, and then this load
averaging scheme becomes even more voluntary than it already was....

anyways, just ramblings and thoughts popping in my head, thought I'd
share...

			Brandon Black