Path: utzoo!attcan!uunet!csinc!rpeglar
From: rpeglar@csinc.UUCP (Rob Peglar x615)
Newsgroups: comp.arch
Subject: Re: Memory utilization & inter-process contention
Summary: The point was slightly missed.
Message-ID: <108@csinc.UUCP>
Date: 24 Aug 89 15:36:57 GMT
References: <3332@blake.acs.washington.edu> <1989Aug22.163100.25540@utzoo.uucp> <9aid02rf4dNn01@amdahl.uts.amdahl.com>
Organization: Control Systems, Inc., St. Paul MN
Lines: 60

In article <9aid02rf4dNn01@amdahl.uts.amdahl.com>, sbf10@uts.amdahl.com (Samuel Fuller) writes:
> 
> In article <26642@shemp.CS.UCLA.EDU> frazier@cs.ucla.edu (Greg Frazier) writes:
> >
> >The original posting was asking if there was an OS smart enough
> >to run the jobs in sequence for him.  That's the point - most
> >machines experience a wide range of workloads, and cannot be
> >customized for each one of them.  Any heavily-used scientific
> >machine is going to experience the described situation at some
> >point in its career. 

(verbiage deleted)

I don't know of any, offhand.  There are a few batch-oriented OSes
out there that allow the user to sequence a series of jobs by informing
the OS (a priori) of the sequence desired.  No funny file games needed.
But, again, the point was the OS doing "automatic sequencing".  Can't
think of one.

> 
> This type of job scheduling is what IBM's MVS operating system does
> very well and what Unix does very poorly.  As far as I know the
> Unix operating system has no concept of job classes.
> The dreaded JCL requires that you tell the system how long your job
> will run, how much memory it will need, and any resources like tape
> drives that you will be using.  Your job is then classified based on
> these parameters.  An MVS system will only allow a certain number of
> jobs to be run in each class.  If your job runs longer than you said
> it would, it is terminated  ungracefully.
> 
> MVS is willing to trade batch throughput for interactive throughput.
> A very heavily loaded MVS system still has excellent interactive response.
> But any big programs, like simulations of future processors, stay
> swapped out of the system until late in the night.

Missed the point.  Many OSes, again, allow a priori resource information
and schedule/control individual jobs (without sequencing as above) and/or
system load, based on the estimates.  No OS (that this addled brain can
think of) solve the optimization problem of maximizing resource utilization
vs. minimizing system throughput, even with knowledge of (N) jobs' initial
conditions, by job sequencing, in a dynamic state (non a priori).

> 
> Unix has the opposite problem.  When a Unix system is very heavily loaded
> everybody notices. Programs run slowly and response time goes to hell.
> 
> Is there a happy middle ground?

Yup.  For example, VSOS has both a priori resource information-based scheduling,
and also dynamic alteration of process state, based on admin-selected memory
utilization criteria.  Both processes and queues can be affected.  It's not
a job sequencer, however.

But it ain't Unix.

Rob

Rob Peglar	...!uunet!csinc!rpeglar
Manager, Software R&D, Workstation Group
Control Systems, Inc., St. Paul MN