Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!caip!lll-crg!lll-lcc!pyramid!amdahl!mat
From: mat@amdahl.UUCP (Mike Taylor)
Newsgroups: net.arch
Subject: Re: Very large memories
Message-ID: <3608@amdahl.UUCP>
Date: Wed, 3-Sep-86 11:40:38 EDT
Article-I.D.: amdahl.3608
Posted: Wed Sep  3 11:40:38 1986
Date-Received: Wed, 3-Sep-86 21:01:14 EDT
References: <5100120@ccvaxa>
Organization: Amdahl Corp, Sunnyvale CA
Lines: 26

Just a few comments on what the large 370 world does about some of the
problems that have been raised with very large memories.  First of all,
large memories in this world are always multi-ported and accessed
through caches. The addressing granularity isn't the byte - it is the
cache line size. Accesses are always made on a line boundary, for I/O
or CPU cache. This simplifies the addressing problem somewhat. It
takes about 15 cycles to service a line fault (15 ns. cycles).
Writes are generally done in background, and both instruction and
operands are prefetched.
Pipeline buffers allow other pipeline stages to keep running if they
can.
A further simplification is third level mainstore - so-called expanded
store - which is only page-addressable. A whole page is copied in and out
of mainstore at a time. This is really a synchronous paging device - such
an operation only takes about 20 microseconds, though, and saves a lot
of overhead associated with doing an I/O.

Some machines (ours, specifically) allow the machine to be subdivided
into hardware VM's, but only a few (4).

2000 user systems (well, almost) are feasible in these environments without
any extreme measures.
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]