Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!kobold!tjt
From: tjt@kobold.UUCP
Newsgroups: net.unix
Subject: Re:  Semi-conductor Disk for VAX
Message-ID: <245@kobold.UUCP>
Date: Mon, 9-Jan-84 16:13:50 EST
Article-I.D.: kobold.245
Posted: Mon Jan  9 16:13:50 1984
Date-Received: Tue, 10-Jan-84 02:20:14 EST
References: <15082@sri-arpa.UUCP>
Organization: Masscomp, Westford, MA
Lines: 35

The reason *why* system performance using a good disk is better than
using main memory as a pseudo-disk is that a DMA disk controller can
transfer data at the same time your processor is doing something useful
(i.e. executing user code, or some more directly useful part of the
system code, such as traversing a path name for a file open).  Using
main memory as a psuedo-disk requires that your processor copy data
back and forth.

On the other hand, a semi-conductor disk also has a controller that
will copy data at the same time a program is executing.  Mike Muuss
<mike@brl-vgr> points out that buying more main memory is a better (and
cheaper?) way of improving your swapping/paging performance since it
greatly decreases the amount of paging you do rather than making it
slightly faster.

Mike goes on to point out that using a semiconductor disk may make
sense for temporary files (i.e. /tmp) since "... no amount of physical
memory devoted to the UNIX buffer cache is likely to be able to cache
the whole thing."  While this is true the way memory and I/O buffers
are currently managed in UNIX (i.e. 4BSD), it is not necessarily true.
There is not good reason why the system should not take over all of
physical memory for I/O bufferring if there is no other demand for the
memory.  This is easier in a system such as Multics which already has a
uniform view of memory, but should not be terribly difficult to add to
UNIX.  Basically, all that is required is to use a common data
structure to keep track of what physical memory is used for, rather
than reserving one pool of physical memory for I/O buffers, and another
for programs.  One way of doing this would be to add a page type (e.g.
CIO) to the cmap structure.  The pageout demon could free this page by
calling bwrite.  You may still to limit the maximum number of pages
used by I/O buffers though if you didn't want to deal with dynamically
allocating and freeing struct buf's.
-- 
	Tom Teixeira,  Massachusetts Computer Corporation.  Westford MA
	...!{ihnp4,harpo,decvax,ucbcad,tektronix}!masscomp!tjt   (617) 692-6200