Path: utzoo!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
Message-ID: <4211@drilex.UUCP>
Date: 31 Aug 89 15:22:16 GMT
References: <3332@blake.acs.washington.edu> <261500008@S34.Prime.COM> <249@gp.govt.nz> <2389@auspex.auspex.com> <4176@drilex.UUCP> <26504@winchester.mips.COM>
Reply-To: dricejb@drilex.UUCP (Craig Jackson drilex1)
Organization: DRI/McGraw-Hill, Lexington, MA
Lines: 44

In article <26504@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>In article <4176@drilex.UUCP> dricejb@drilex.UUCP (Me) writes:
>......
>>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.
>
>Say some more.  I'd assume there's a trap-on-write bit or equivalent
>somewhere, but no modified bit set by hardware?
>
>Note that on a paged machine running UNIX, with typically-sized pages
>(i.e., fairly different from A-series, I think), hardware-set modified
>bits are unlikely to consume much bandwidth, unless done by blindly
>writing a page table entry upon every write (as opposed to state
>changes). This why it is easy to get away with trapping writes to
>set modify bits instead of having the hardware do it.
[ more analysis of Unix write patterns.]

The A-Series hardware essentially has a trap-on-write bit in each
segment descriptor.  Code segments are read-only by definition; data
segments have a bit in the descriptor.  These could be used by an
operating system to detect modified segments, and deal with them.
(At least the data segments could.)  However, the operating system
does not do this: Either the data has been marked read-only by the
compiler, or it is assumed to be read/write.  Read-only data and
code are assumed to be unchangeable throughout execution; they're
always retrieved from the object code file, rather than the page
file.

The reason why there could be quite a bit of traffic for modify
bits is that the A-Series is a segmented machine.  The average
segment size (about 600 bytes on our machine) is much smaller
than the typical Unix page.  Note that the smaller machines in
the A-series do have modified bits; I guess they decided the extra
I/O traffic would be more important than the memory traffic.

However, I still don't understand why they left off the bits
on the large boxes.  They're caching the writes; why couldn't they
cache the modified bit updates too?
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}