Xref: utzoo comp.arch:11073 comp.sys.mips:93
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ucla-cs!oahu!frazier
From: frazier@oahu.cs.ucla.edu (Greg Frazier)
Newsgroups: comp.arch,comp.sys.mips
Subject: Re: Memory utilization & inter-process contention
Message-ID: <26642@shemp.CS.UCLA.EDU>
Date: 22 Aug 89 20:37:34 GMT
References: <3332@blake.acs.washington.edu> <1989Aug22.163100.25540@utzoo.uucp>
Sender: news@CS.UCLA.EDU
Reply-To: frazier@cs.ucla.edu (Greg Frazier)
Organization: UCLA Computer Science Department
Lines: 29

In article <1989Aug22.163100.25540@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
=>In article <3332@blake.acs.washington.edu> lgy@newton.phys.washington.edu (Laurence Yaffe) writes:
=>>suppose you have a 32 Mbyte system and that there are only two processes
=>>running, each of which uses 25 Mbytes of virtual memory (almost all data space)
=>
=>Have you ever figured out how long it takes to swap out a 25MB process?
=>Or to swap it back in again?  The fact is, this example system simply
=>does not have enough main memory for its workload.  The fix is, either
=>double the memory or run the jobs in sequence rather than simultaneously.

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! :-)

Greg Frazier
&&&&&&&&&&&&&&&&________________________@@@@@@@@@@@@@@@@@@@@
Greg Frazier	    o	Internet: frazier@CS.UCLA.EDU
CS dept., UCLA	   /\	UUCP: ...!{ucbvax,rutgers}!ucla-cs!frazier
	       ----^/----
		   /