9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Photon photon@nol.net
Subject: "cpu" command, other related stuff
Date: Sun, 25 Aug 1996 17:45:13 -0500	[thread overview]
Message-ID: <19960825224513.iJhxMt3fpfYlKUXiNhHOXxhp7WJgviu0HEjqAwT9dy4@z> (raw)


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






             reply	other threads:[~1996-08-25 22:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-08-25 22:45 Photon [this message]
1996-08-26  8:39 Boyd
1996-08-27  7:07 Nigel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19960825224513.iJhxMt3fpfYlKUXiNhHOXxhp7WJgviu0HEjqAwT9dy4@z \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).