Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: Memory utilization & inter-process contention
Message-ID: <44670@bbn.COM>
Date: 23 Aug 89 16:39:32 GMT
References: <3332@blake.acs.washington.edu> <1989Aug22.163100.25540@utzoo.uucp> <26642@shemp.CS.UCLA.EDU>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 24

In article <26642@shemp.CS.UCLA.EDU> frazier@cs.ucla.edu (Greg Frazier) writes:
>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:
>=>Have you ever figured out how long it takes to swap out a 25MB process?
>=>Or to swap it back in again?

>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 ...

That was one of the best things (I thought) that VMS has: the ability
to set up batch queues of different priorities, and set the number of
jobs in progress at each level.  On two large programs I worked on,
there were some large simulations and many small ones.  Interactive
jobs were set at level 4, so they got done first.  We set up level 3
(lower priority) with a job limit of 2 or 3 for the small jobs, and
level 2 (even lower) for the huge ones that ran for, oh, 6 hours and
used megabytes, with a job limit of 1.  The only time the machine was
idle was right after a reboot.

We found that there should be more than one job available, so
something useful happens during paging (assuming your machine pages).
-Stan