Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!spdcc!merk!alliant!cantrell
From: cantrell@Alliant.COM (Paul Cantrell)
Newsgroups: comp.sys.alliant
Subject: Re: job classes
Message-ID: <4068@alliant.Alliant.COM>
Date: 15 Aug 90 19:05:49 GMT
References: <1990Aug10.112530.720@eagle.lerc.nasa.gov> <4059@alliant.Alliant.COM> <1990Aug14.115752.23746@eagle.lerc.nasa.gov> <1990Aug14.194125.9771@odin.corp.sgi.com>
Reply-To: cantrell@alliant.Alliant.COM (Paul Cantrell)
Organization: Alliant Computer Systems, Littleton, MA
Lines: 68

Disclaimer: The following is a non-official reply, don't take any of it as
	official Alliant policy or position or my boss will yell at me ;-)

In article <1990Aug14.194125.9771@odin.corp.sgi.com> dereks@aggie.sgi.com (Derek Spears) writes:
>	Just specifying -Ogv wil generate vector code and no cocurrency code.

Correct.

>However, the scheduler you posted still had classes 2 and 3 on the
>complex. Therefore, when the complex switches on during its time slice,
>it will see that it has a class 2 job (vector) and try to run it. I
>agree that it is not the most intuitive apporach, but that is how the
>Alliant scheduler does things...

Correct again, but only if there are no concurrent (class 1) jobs to run,
since they would get priority over the class 2 and 3 jobs. The idea here
is that if the complex got put together to run concurrent jobs, runs them
all to completion and has nothing else to do, it may as well run class 2
or class 3 jobs until the end of the resource timeslice.

Note that when it does this, only one of the members of the complex actually
run user code, and the other members just hang out idle. So it is acting
exactly like a CE in this case.

You might ask yourself, why is the complex getting put together if there are
no complex jobs to run?

The answer is that the -tc switch in the scheduling vector says that if there
are any concurrent jobs at all, put the complex together. It also says that if
there are no concurrent jobs and no non-concurrent jobs (i.e. no jobs at all)
go ahead and put the complex together anyway. If non-concurrent jobs then
become runnable, they will run on the complex until the end of the timeslice
at which point it would probably explode.

The reason for putting it together if there are no jobs at all is a
response issue. It's fairly time consuming to put the complex together,
and easy to take the complex apart, so this switch just anticipates
that complex jobs may become ready to run in the near future.

If you run a mix of concurrent and non-concurrent jobs, you might want to
try something like:

	setcomplex cl 0 -c1 -d8
	setsched cl 0 -td 35 1 2 3 -t 35 1 3 2

the result of which is that during the first (-td) timeslice, the complex
will get put together if there are any concurrent jobs, as long as there
are less than 8 non-concurrent jobs.

During the second (-t) timeslice, if there are more concurrent jobs than
non-concurrent, the complex will be put together, otherwise it will be
exploded to run as detached CEs.

This way, concurrent jobs get at least 50% of the system up until there are
more than 8 outstanding non-concurrent jobs, at which point the complex
jobs will get ignored until the backlog of non-concurrent jobs is decreased.
However, the complex will never get put together when there are no concurrent
jobs to run.

One final note: many people are confused by the complex schedule. The
classes in each complex timeslice only get used if the complex is put
together for that timeslice. If the complex is exploded, each individual
CE's schedule controls what gets run, and the classes in the complex
scheduling vector are ignored.

Hope you find this somewhat helpful.

					Paul Cantrell