🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #1931

Re: Memory utilization & inter-process contention

#1931
From: Samuel Fuller
Date: Wed, 23 Aug 1989 02:00
45 lines
2880 bytes
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.  Now, obviously, if you have somebody
>monitoring the machine's performance, he can "manually" prevent
>the two jobs from running simultaneously.  What would be more
>desireable, however, is for the OS to realize what is going on,
>and for _it_ to cause the jobs to run sequentially.  I suspect
>that this would require too much intelligence on the part of the
>OS, but then, what do I know - I'm just an architect! :-)

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.

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?
-- 
---------------------------------------------------------------------------
Sam Fuller / Amdahl System Performance Architecture

I speak for myself, from the brown hills of San Jose.

UUCP: {ames,decwrl,uunet}!amdahl!sbf10 | USPS: 1250 E. Arques Ave (M/S 139)
INTERNET: sbf10@amdahl.com             |       P.O. Box 3470
PHONE: (408) 746-8927                  |       Sunnyvale, CA 94088-3470
---------------------------------------------------------------------------
Technical Details
Message-ID: <9aid02rf4dNn01@amdahl.uts.amdahl.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amdahl!sbf10
References: <3332@blake.acs.washington.edu> <1989Aug22.163100.25540@utzoo.uucp> <26642@shemp.CS.UCLA.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amdahl!sbf10
From: sbf10@uts.amdahl.com (Samuel Fuller)
Newsgroups: comp.arch
Subject: Re: Memory utilization & inter-process contention
Message-ID: <9aid02rf4dNn01@amdahl.uts.amdahl.com>
Date: 23 Aug 89 02:00:14 GMT
References: <3332@blake.acs.washington.edu> <1989Aug22.163100.25540@utzoo.uucp> <26642@shemp.CS.UCLA.EDU>
Reply-To: sbf10@amdahl.uts.amdahl.com (Samuel Fuller)
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 45