Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bbn!drilex!dricejb
From: dricejb@drilex.UUCP (Craig Jackson drilex1)
Newsgroups: comp.arch
Subject: Re: Memory utilization & inter-process contention
Summary: Try Unisys' A-Series MCP
Message-ID: <4176@drilex.UUCP>
Date: 29 Aug 89 16:02:01 GMT
References: <3332@blake.acs.washington.edu> <261500008@S34.Prime.COM> <249@gp.govt.nz> <2389@auspex.auspex.com>
Reply-To: dricejb@drilex.UUCP (Craig Jackson drilex1)
Organization: DRI/McGraw-Hill, Lexington, MA
Lines: 64

In article <2389@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>I must be lucky then.  VMS has had one since day one.  Working set 
>>parameters can be set by either authorization information, as parameters 
>>to the $CREPRC system service (which creates a process) or explicitly 
>>during process execution (SET WORKING_SET command, or $ADJWSL system 
>>service).
>
>OK, so which of the OSes that support working set scheduling do so
>without having to be told by some external agent what the working set of
>a process at some given time is?  (Do the VMS calls even tell the OS
>that, or do they just tell it how big the working set is?)

The older operating system, called MCP, on the Unisys A-Series did
classic working set maintenance, without either a referenced bit
or a modified bit.  It did use some form of a clock algorithm to
figure out what to throw out, but maintained working sets to determine
how much of each task's memory to throw out.  The working set calculations
were based on things like the number of segments faulted-in in a given
period and their size.

Interestingly, the operating system for their latest architecture, called
MCP/AS, punts all of the working set stuff, replacing it with a simple
clock algorithm with two hands.  There is only one memory pool, consisting
of the entire machine.  This allows a low-priority user task to suck up
lots of memory, until both it and high-priority tasks begin to page.  The
low-priority task doesn't mind, but everybody else suffers.  (Lots of the
the code which is equivalent of the Unix kernel is pagable on this system.)
The vendor response was to buy more memory; we're up to 144MB and still
hurting occasionally.  Their next response was "Don't run big-memory jobs".

This issue points up one other thing: this operating system runs fine as
a transaction-processing monitor, where there are relatively few tasks
to be run, and each task performs a well-defined function.  This is the
direction that mainframes are going.  In practice, most mainframes have
already conceded the time sharing realm to other processors (Unix, PCs, etc.).
The main refuge of mainframes today is serious bean-counting, and servicing
the "operators standing by to take your order".

(This gratuitous comment brought to you through fear of the
inews line-counter.)

>Jerry Leichter claimed that the VMS software people showed that a
>reference bit is not necessary, given the appropriate algorithms; does
>VMS how have appropriate algorithms to determine the contents of the
>working set without requiring a reference bit, or did the designers
>decide that the appropriate algorithm is to believe what the user or the
>application tells you and not try to figure it out for yourself?  (Not a
>rhetorical question - I'm willing to accept that the latter is the
>appropriate algorithm, given sufficient evidence to demonstrate that
>claim.)

I think that the VMS guys thought that the ability to recover pages off
the free list gave them many of the features of reference bits, without
either the memory traffic to update them or the software effort to read
them.

P.S. The largest processors of the Unisys A-Series still don't have
modified bits.  The designers decided that the memory traffic would be
too high.  However, code and read-only arrays (declared at compile time)
has been marked specially for years, and need not be paged out.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}